mintty 3.6.4 status line problem

[Ross Boulet via Cygwin]

I was looking at the settings for mintty and saw the new option (new as of 
3.6.4 from March) for a status line. I decided to try it out. Sure enough, a 
status line appeared at the bottom. All was well until I tried to open a new 
mintty window and nothing seemed to happen. After a little research, I saw a 
stackdump was being generated. I had to get to the .minttyrc file and remove 
the StatusLine=yes to get it to work again. I tried the same scenario on 
another Windows 10 machine as well as a Windows 11 machine with the same 
results.

To reproduce the problem, right click on the icon in the upper left corner of a 
mintty window and choose options. On the options dialog, choose terminal and 
check the option to turn on the status line. Then click save. The current 
window shows a status line but attempts to start a new window will fail and 
generate a stackdump.

--
Ross Boulet
Boulet and Associates
713.202.3567
-



cygcheck.out
Description: cygcheck.out

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Invoking ash for rebaseall

[Ross Boulet]

My apologies if this is covered somewhere (FAQ, user guide,
etc.)  Rebaseall now requires being run under ash, but when
I run ash from "Start/Run" or from a cmd.exe prompt, it does
not execute /etc/profile and therefore does not have a path
to rebaseall (or any other cygwin directory for that
matter).

Granted, I could go in to windoze and add the cygwin
directories to my system path, or manually source
/etc/profile at the ash prompt.  But is there a flag to tell
ash to act as a login shell and execute /etc/profile?

Thanks,
Ross





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: automatic generation of resolv.conf

[Ross Boulet]

> On Jun  9 15:25, Brian Dessent wrote:
> > Ross Boulet wrote:
> > > I recently downloaded and compiled dig from the bind
> > > website.  [...]
> >
> > Since that functionality already exists, your best bet
> would be to
> > either a) use the win32 port b) patch dig to include
> that functionality
> > when compiling with Cygwin.
> 
> When building dig on Cygwin, its configury should find
> that libresolv
> already exists and link against it.  It's the minires and
> minires-devel
> packages you need for that.
> 
> 
> Corinna

I did not have minires-devel installed.  I have installed it
and run:

$ make clean
$ ./configure
$ make

The resulting dig.exe is still looking for nameservers in
resolv.conf.  Am I missing a step for integrating
minires-devel?

Thanks.
Ross




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

automatic generation of resolv.conf

[Ross Boulet]

I recently downloaded and compiled dig from the bind
website.  When I tried to run it, it wouldn't work unless I
specified the DNS server on the command line.  Looking at
the man page on a Linux box, I saw a reference to
resolv.conf (which is obviously not present by default in
Windoze.  Creating a resolv.conf with my ISP's name servers
in it fixed the issue.

I saw some posts from a while back where someone was
thinking about a utility to create the resolv.conf file for
some other application that was expecting its presence.
Does anyone know if this ever got further than the idea
phase?  I use a laptop in a lot of different places and the
name servers vary from place to place, depending on the ISP.
I could just hard code the resolv.conf, but it would be
helpful to see the data my clients are seeing without having
to redo resolv.conf each time.

Thanks in advance for the help.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Wildcards in the path name parameter

[Ross Boulet]

> On 26/05/05, Coetzee, Evert wrote:
> > But I'm running it from the cmd.exe command prompt. I'm
> not in a shell.
> >
> > cp: cannot stat `/cygdrive/c/*.*': No such file or
> directory
> >
> > That is the error I get now.
> 
> Do you have "noglob" in your CYGWIN environment variable?
> http://cygwin.com/problems.html
> 
> Lev
> 
Just to experiment with globbing, I created a small c
program to list the command line arguments.  I read where
the cygwin dll will do globbing for a program run from a
windoze command prompt, so I compiled with -mno-cygwin.
Much to my surprise, globbing is still occurring, even from
a windoze prompt.  How can this happen?


#include 

int main(int nArg, char **cArg)
{
  int i;
  for ( i = 0 ; i < nArg; i++ )
  {
printf("%s\n",cArg[i]);
  }
  return 0;
}

$ make
gcc -mno-cygwin -o parseline parseline.c

$ cygcheck parseline.exe
Found:
C:\cygwin\home\rossboulet\Program\c\parseline\parseline.exe
C:/cygwin/home/rossboulet/Program/c/parseline/parseline.exe
  C:\WINDOWS\system32\msvcrt.dll
C:\WINDOWS\system32\KERNEL32.dll
  C:\WINDOWS\system32\ntdll.dll

$ ./parseline *
C:\cygwin\home\rossboulet\Program\c\parseline\parseline.exe
makefile
parseline.c
parseline.exe

$ cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\cygwin\home\rossboulet\Program\c\parseline>parseline *
parseline
makefile
parseline.c
parseline.exe





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: "ls" finds file1 but "ls file1" does not

[Ross Boulet]

> >> [etc]  Did your ash script go wrong and rename all
> those files with
> actual
> >> asterisks on the end ?
> 
> > The * in the listing just indicates that the file is
> executable (an ls
> > option that I use by default).
> 
> 
>   Hey, just wondered.  It happened to me once
> 
> 

I'm wondering if something else happened in the renaming
script.  Is it possible there is a space (or some other
non-printable character) as the first character of the file
names?  The output on a couple of messages leads me to
believe so.  When I do an "ls -l", there is only one space
between the date and the file name, in Charles's output,
there are two.  I'd be interested to see the output of:

ls \ *

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: "ls" finds file1 but "ls file1" does not

[Ross Boulet]

> > "ls" finds file1 but "ls file1" does not.  How can this
> happen?
> >
> > The following example occurred just after I had renamed
> some *.htm files
> > to *.html using
> > an ash shell script.  No such problem occurred, however,
> when I used DOS
> > "rename" to make
> > the same change.
> 
>   Not 100% sure what's going on here, but can I just ask
> one thing?
> 
> > $ ls
> > _index.htm*    finder.dat* lib_over.htm*
> setjmp.htm*   time.htm*
> > assert.htm*    float.htm*  lib_prin.htm*
> signal.htm*   types.htm*
> > charset.htm*   function.htm*   lib_scan.htm*
> stdarg.htm*   wchar.htm*
> 
> [etc]  Did your ash script go wrong and rename all those
> files with actual
> asterisks on the end ?
> 
> > Documents/books_open/c/stdcbook_bad/STD_c
> > $ ls assert.htm
> > ls: assert.htm: No such file or directory  <--  
> THIS IS THE PROBLEM
> > 
> 
>   But ISTM there is no such file as assert.htm.  What
> output do you get from
> 
> ls assert.htm\*
> 
>    ?
> 
 
 
ls is acting like the -F option is specified which would
cause the '*' to be displayed at the end of any file name
which is executable (as one prior message shows these files
are).  Under what shell is ls being run and is there an
alias for ls that is causing this option to be invoked?  If
so, are there any other options in the alias?
 
 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

snapshot not stripped

[Ross Boulet]

This is just a curiosity question.  When did the cygwin
snapshot dll's quit being stripped?  I was experimenting
today and downloaded the 20050311 snapshot.  When I unzipped
it, it was over 8MB.  Once I stripped it myself, it was more
in line size wise with other snapshots I have downloaded.

The snapshot download page says they are supposed to come
stripped.  Therefore, I would suggest either stripping the
dll's again or changing the download page to reflect the
fact that the snapshots are no longer stripped if that is
the intention.

--

I was going to buy a copy of "The Power of Positive
Thinking," and then I thought: What the hell good would that
do? 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: New cygwin1.dll release urgently needed

[Ross Boulet]

I'm assuming you meant to reference the released dll of
1.5.13 and the snapshot of 20050311 (instead of 2004).
bunzip2 WFM under the released dll.  Your problem probably
lies elsewhere and it would be helpful if you followed the
problem reporting guidelines shown at:
http://cygwin.com/problems.html


> Hi,
> 
> I have been updating cygwin. There is the following
> problem:
> bunzip2.exe does not function properly with cygwin1.dll-
> 15.13-1.
> I does function with the snapshot 20040311, but if you
> have updated
> to cygwin1.dll-15.13-1 you can't expand the 20040311
> snapshot. I had
> to use an old cygwin1.dll of 20041217 I had around. I
> suggest to
> release immediately the new cygwin1.dll.
> 
> Bye
> R. Medina
> 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: stupid noobquestion(clear)

[Ross Boulet]

> Is there a command for clearing the console?
> Can't get cls,clr,clear to work :(
> 
> /
> Acke
> 
Did you download and install the "clear" package?  Its under
"Utils".

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: system call

[Ross Boulet]

> Thanks for your reply but it still do not work...
> the problem is thant under cygwin the execution of "dir"
> works fine but i have to run the program in an enviroment
> WITHOUT cygwin: it's in the DOS shell that the system()
> call do not works and return with code number 127.
> In the final application, i'll not use "dir" command, but
> another program.
> 
> Muzero
> 
> > On Mar  1 09:58, Muzero wrote:
> > > When i try to compile and execute a simple program
> like this:
> > >
> > > int main()
> > > {
> > >   system("dir");
> > >   return 0;
> > > }
> >
> > "dir" is a cmd.exe builtin.  Try `system("cmd /c dir");'
> >
> > Corinna
> >

Have you tried adding the -mno-cygwin option when you
compile the program.  This should eliminate the need for the
cygwin environment at run time.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Graduate Student needs help/information.

[Ross Boulet]

> On Mon, Feb 14, 2005 at 08:59:37PM -0600, Nick Leeson
> wrote:
> >Hello All,
> >I am a graduate student researching the Open Source
> Development Model.
> >For my emperical study, I need a list of core cygwin
> developers and/or
> >maintainers. I would use this list to parse through the
> messages in
> >the mailing lists and compute statistics of interest. Can
> someone
> >provide me a pointer to where I can get this list.
> Usually this list
> >is found in the  MAINTAINERS file in the sources, but I
> could not find
> >any such file. I downloaded the sources via CVS but it
> was not of much
> >help.Can somebody help me?  I would really appreciate.
> 
> http://cygwin.com/who.html
> 
> cgf
> 
There are a couple of bad links on the above referenced
page.  The "free software projects" in the 6th paragraph and
the "GNUPro Toolkit" link in the last paragraph don't work
for me.

Ross

--

I was going to buy a copy of "The Power of Positive
Thinking," and then I thought: What the hell good would that
do? 




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Is Cygwin cron supposed to send e-mail reports?

[Ross Boulet]

[snip]
> 
> I dunno either, but gave it a try anyway:
>
> [EMAIL PROTECTED]:~$ rebaseall
> ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last
error = 6
> [EMAIL PROTECTED]:~$ rebaseall
> ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last
error = 6
>
>
[snip]

Make sure when you run rebaseall that you first stop any
cygwin processes that are running(sshd for example),
otherwise, rebaseall can't get to the dll's.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: du reports half of correct file sizes

[Ross Boulet]

> Ross Boulet wrote:
> > 
> > I saw some old items in the archives (circa 2001) but
there
> > was not much there about this problem.  The most recent
> > version of coreutils seems to have broken du.  The
listing
> > below illustrates my point:
> 
> If you have POSIXLY_CORRECT set in your environment then
the default
> block size for du is 512 bytes, which is what the posix
standard
> requires.  Use -b or -k if you want bytes or kbytes,
respectively.
> 
> Brian
> 
>

I do not have POSIXLY_CORRECT set.  I tried the -b and -k
options.  The -b option reports correctly, but the -k still
seems to report half.

$ ls -l a*
-rw-r--r--  1 rossboulet None2 Dec 25 17:24 a
-rw-r--r--  1 rossboulet None 3740 Dec 25 10:58 aaa

$ du -b a*
2   a
3740aaa

$ du -k a*
1   a
2   aaa



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

du reports half of correct file sizes

[Ross Boulet]

I saw some old items in the archives (circa 2001) but there
was not much there about this problem.  The most recent
version of coreutils seems to have broken du.  The listing
below illustrates my point:

$ ls -l a*
-rw-r--r--  1 rossboulet None2 Dec 25 17:24 a
-rw-r--r--  1 rossboulet None 3740 Dec 25 10:58 aaa

$ du -a a*
1   a
2   aaa

$ du -ah a*
512 a
2.0Kaaa


--

I was going to buy a copy of "The Power of Positive
Thinking," and then I thought: What the hell good would that
do? 



cygcheck.out
Description: Binary data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Handling of /etc/profile.d broken?

[Ross Boulet]

> Hi,
> 
> I've just noticed a weird problem:
> When I set an environment variable in a script in
> /etc/profile.d, I never see it in my shell.
> For example, take
> 
>  /etc/profile.d/blub.sh:
> export blub=1
> 
> 
> Adding "echo $blub" to the loop in /etc/profile,
> I can see that it gets set, but is unset immediately
> after the loop.
> 
> The attached patch changes the loop from the
> "find ... | while ..." idiom to "for f in `find ...` ...",
> and that works.
> 
> Is it true that the "|" starts a new sub-shell, which
> makes all the "export" commands and the use of the
> "source" (".") obsolete? What a pity.
> 
> I wonder whether it has been like that all the time,
> and I'm the only one who's so stupid as to try and set
> environment variables in /etc/profile.d?
> 
> Funny world ;-) Any hints?
> 
> Best wishes,
>   Jan.

WFM under both bash and pdksh.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Need copy of /etc/profile

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf
> Of [EMAIL PROTECTED]
> 
> I very stupidly overwrote my /etc/profile file. Can someone send me
> (directly or through the mailing list) a pristine copy of it, or is there
> a way to get just that file from CYGWIN's setup?
> 
> (very embarrassed)
> Larry
> 

Try looking for /etc/defaults/etc/profile.

HTH



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: problems with script

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of Christopher Spears
> 
[ ... ]
> > >
> > > #get argument name
> > > set dest = $argv[1]
[ ... ]
> > > following command line:
> > > (date; du ~) | ./ppd.txt ~/disk_storage&
> > >
[ ... ]
> 
> I changed the first line to "!/bin/tcsh -x", and then
> tried to run the script again.  Here are the results:
> 
> set tf = /tmp/ppd.1316
> set dest = /home/Christopher Spears/disk_storage
> set: Syntax error
> 
> So it seems the first two lines work...Right?  What is stderr?
> 
Looks to me like the "set dest" line is choking because you have a space in
your home directory name.  Try using double quotes such as:

set dest = "$argv[1]"

and again anywhere $dest is used.

As an alternative, change your home directory name to not have a space and
modify /etc/passwd accordingly.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: 1.5.9: tcsh 6.12.00 parses scripts wrong with DOS line endings

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of David Mastronarde
> 
> When csh scripts have DOS line endings, tcsh 6.12.00 
> sometimes parses them 
> incorrectly.  This seems to happen with scripts that have 
> while loops, 
> once the scripts get big enough.  Converting the script to unix line 
> endings fixes the problem.
> 
> The attached script, cshbug, is about as small as it can be 
> to show the 
> problem.  It needs to be run with a valid argument, in my case
> cshbug -inst /usr/local/IMOD
> 
> The standard error output is:
> =: Command not found.
> 
> The attached file bugout2 is the output from
> csh -v cshbug -inst /usr/local/IMOD
> 
> After the first trip through the while loop, it jumps back up to the 
> middle of a line before the loop:
> = "unsigned int"
> 
> If the variable setting section of the script is made 
> smaller, such as 
> by removing the first 13 lines, the problem goes away.
> 
> This problem has been present for the past year at least.
> 
> David Mastronarde
> Boulder Laboratory for 3-D Electron Microscopy of Cells
> 

FWIW, looking at your cshbug.txt file, I see that the line endings are
unusual.  A normal DOS line ending is a  combination.  Your file
seems to have an extra  at the end of each line.  Each line ends with
.  My guess is when tcsh is processing the script, it does not
count the extra  characters, so when it loops, its offset into the
script is off by a number of characters equivalent to the number of extra
s.  In other words, the while statement in the script is on line 101.
When it loops, tcsh is jumping to a location in the file calculated by
assuming the size of the lines plus a two character line ending, not three.
Therefore, the jump location is off by the number of bytes (101) its trying
to get to.

The script is 190 lines long. If you run dos2unix on the file, the resulting
file is 380 bytes smaller, having dropped two  per line.  Running
unix2dos on the result increases the file size by only 190 (one  per
line).  I'd be curious whether this resulting file with "normal" DOS line
endings works correctly for you.

I don't know if tcsh should handle the extra 's or not.  But perhaps my
observation will at least narrow down where to look.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cygpcre-0.dll not found message

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of James Adams
> Sent: Monday, April 05, 2004 11:55 AM
> 
> 
> Thanks for the info Larry, I'll give it a try pronto.
> 
> 
> -James
> 
> 
> -Original Message-
> From: Larry Hall [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 05, 2004 12:50 PM
> To: James Adams; [EMAIL PROTECTED]
> Subject: Re: cygpcre-0.dll not found message
> 
> At 12:22 PM 4/5/2004, you wrote:
> >I tried using "less" for the first time today with a fresh 
> installation
> of 
> >Cygwin (version 1.5.9-1) and I got an error message telling me that
> "The 
> >dynamic link library cygpcre-0.dll could not be found in the 
> specified
> path".  
> >How can I remedy this situation ?  I have searched for this 
> file and it
> is 
> >indeed absent.
> >
> >Thanks in advance for any feedback.
> 
> 
> This kind of question can always be answered by visiting 
>  and typing the name of the file you're
> missing ('cygpcre-0.dll' in this case).  The result will tell you the 
> name of the package you need to install via setup (libpcre0 for your
> situation).  Try it.  It works. ;-) 
> 

I saw the same behavior today on two machines.  I believe there is something
broken in setup's dependencies.  I did a fresh install without selecting any
packages and let setup install just the basics.  After the first run of
setup, running "less" popped up an error complaining about cygpcre-0.dll not
being found.

I ran setup a second time, again without selecting any packages, and on the
second pass, setup installed two more packages - libbz2_1 and libpcre0.
This corrected the issue with less.

I don't know enough about setup and how it decides which packages to
install, but I don't think this behavior is as intended.  I'm attaching two
cygcheck output files (one after the first run of setup and one after the
second).

I repeated the process on a different mirror with the same results.

Ross

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Thu Apr 08 12:06:22 2004

Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 1

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\ATI Technologies\ATI Control Panel

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1007(KaiBike) GID: 513(None)
513(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1007(KaiBike) GID: 513(None)
0(root)  513(None)
544(Administrators)  545(Users)

SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS

HOME = `C:\cygwin\home\KaiBike'
MAKE_MODE = `unix'
PWD = `/home/KaiBike'
USER = `KaiBike'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\KaiBike\Application Data'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `LAP2004'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\KaiBike'
HOSTNAME = `LAP2004'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\LAP2004'
MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man:'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/etc/skel'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0209'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOCUME~1\KaiBike\LOCALS~1\Temp'
TERM = `cygwin'
TMP = `c:\DOCUME~1\KaiBike\LOCALS~1\Temp'
USERDOMAIN = `LAP2004'
USERNAME = `KaiBike'
USERPROFILE = `C:\Documents and Settings\KaiBike'
WINDIR = `C:\WINDOWS'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
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
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   38107Mb  18% CP CS UN PA FC 
d:  cd   N/AN/A 

RE: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of Charles Wilson
> Sent: Sunday, April 04, 2004 11:33 PM
> 
[...]
> 
> I think there is some misunderstanding about the cygutils package.  I 
> did not write any of it.(*)  I do not defend any of the 
> design decisions 
> that were made by the original coders; it's no skin off my nose -- so 
> comments like "It should according to the thinking in this 
> thread." fail 
> to move me -- except as a data point that GVanSickle really REALLY 
> dislikes the current behavior.
> 
[...]

What was the original source of these programs and has the same discussion
already been hashed in that arena?

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Problems with OpenSSH in win32.

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of Brian Chase
> 
> Are you sure of this statement?  The reading I have done on TightVNC 
> tells me it encrypts passwords only and doesn't have any SSH 
> capabilities.  I'd be happier if I were not correct, but I'd 
> like to read 
> some documentation proving me wrong to confirm it.
> 
> Alejandro Lopez-Valencia wrote:
> 
>   And
> > that's the reason why I suggested TightVNC, performance is 
> acceptable
> > with a 56K modem link, and it defaults to using SSH 
> tunneling, so for
> > practical purposes you obtain a cheap VPN.
> > 
> > And now back to your original broadcast.
> > 
> 
I may be talking out of school here, but I've used ssh to tunnel other IP
based protocols such as POP3, SMTP, and printing.  The application doesn't
have to know about ssh.  ssh just has to be told which IP ports to forward.
For example:

ssh -L 515:127.0.0.1:515 myhost

Tells ssh to start a session with myhost and forward IP port 515 to the same
port on myhost.

I would assume the same thing can be done for TightVNC using whatever ports
it requires.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: g77 (new), Windows XP Professional, CALL System(Command, Status), directory.

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of Igor Pechtchanski
> Sent: Monday, March 22, 2004 7:12 AM
> 
> On Mon, 22 Mar 2004, Lars Steinke wrote:
> 
> > >On Sat, 20 Mar 2004, Lars Steinke wrote:
> > >
> > >> Hello,
> > >>
> > >>   call system('cmd.exe /c cls')
> > >>
> > >> works! Thank you Dave!
> > >>
> > >> Now I have a new problem with 'call system':
> > >> I wolud like to start a batch-file named '1.bat'.
> > >> 1.bat and my program are in the same directory (C:\test).
> > >>
> > >>   call system('1.bat')
> > >>   pause
> > >>   end
> > >>
> > >> Error-message:
> > >>
> > >> 1.bat: not found
> > >>
> > >> If i add the directory to the PATH:
> > >>
> > >> PATH=%PATH%;C:\test
> > >>
> > >> it works, but normally the current directory should be 
> scanned, also if
> > >> it is not in the PATH...?
> > >>
> > >> If I try to start my program from the cygwin-shell 
> (current directory is
> > >> the directory where the program is saved) i get the following
> > >> error-message:
> > >>
> > >> bash: a.exe: command not found
> > >>
> > >> This is no 'call system'-problem, but mayby there is a 
> correllation.
> > >>
> > >> Thank you very much, Lars.
> > >
> > >Lars,
> > >
> > >In Cygwin, like in most Unixes, and unlike Windows, "." 
> (the current
> > >directory) has to explicitly be in the PATH for programs 
> to be found there
> > >(see ).  As the 
> FAQ says, you can
> > >prepend "./" to the name of the program in the current directory.
> > >Alternatively, you can add "." to the PATH, either in your 
> environment, or
> > >via a "putenv" call if FORTRAN supports it.
> >
> > Ok, but I have the same situation in Windows and in windows 
> normally the "." should be scanned, also if it is not in the PATH.
> > If my program tries to invoke 1.bat (Win-shell) it fails 
> (1.bat: not found), although it is in the same directory (and 
> it is not a builtin command).
> > If I try to compile:
> >
> >   CALL System('.\1.bat')
> >
> > ?.bat: not found
> >
> >
> >   CALL System('cmd.exe /c 1.bat') works, but 1.bat is 
> not a builtin command...?
> >
> >
> > >P.S. FYI, system("cmd /c cls") won't work on Win9x.
> >
> > Is there a command which fits both?
> > Thanks, Lars.
> 
> Wrong slash.  Try
> 
>   CALL System('./1.bat')
> 
> As for Win9x, they use "command.com", not "cmd.exe"...  I 
> doubt there's a
> command that'll do both (unless you get the value of the COMSPEC
> environment variable and use that)...  You can also use the "clear"
> command (in the "clear" package).
> HTH,
>   Igor

This is probably way OT for this list, but AFAIK, command.com continues to
be provided on Windows, so

   CALL System('command.com /c 1.bat')

Might work from Windows 9x all the way to 2003 Server.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cp.exe bug

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of Dave Korn
> Sent: Tuesday, March 16, 2004 12:17 PM
>
> > From: cygwin-owner On Behalf Of LarrysPCRemedies at aol.com
> > Sent: 16 March 2004 17:36
> 
[ snip. ]
> 
> #4)  Just revert your coreutils.  Didn't someone say it was 
> working in the
> previous version?  Then it should still be ok in most other 
> regards.
> 
> 
One minor comment - currently its fileutils on cygwin.  Fileutils,
textutils, and sh-utils are being combined in to coreutils, but the combined
coreutils has not yet been released AFAIK

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cp.exe bug

[Ross Boulet]

> -Original Message-
> From: cygwin-owner On Behalf Of Dave Korn
> Sent: Monday, March 15, 2004 4:50 AM
> 
> > I cut more from my makefile and just use one symbolic in 
> > place of your BIN, OBJ, and FILE as follows:
> > 
> > ### Even More Simple Makefile Example
> > 
> > CC= gcc
> > 
> > FILE= foo
> > 
> > all: $(FILE).exe install
> > 
> > $(FILE).exe: $(FILE).o
> >  $(CC) -o $(FILE).exe $(FILE).o
> > 
> > $(FILE).o:
> >  $(CC) -c $(FILE).c -o $(FILE).o
> > 
> > install:
> >  mkdir -p ./bin/;
> >  cp $(FILE).exe ./bin/;
> > 
> > ### End Makefile
>  
> 
>   I can't reproduce the problem here:
> 
> 

Dave,

Thanks for the response, but this makefile was my attempt at getting around
Alan's issue.  I have re-pasted his makefile below which gives the error he
saw.  I have found a different way to reproduce the error message as well.

[ snip ]
> 
> 
>   Dunno why.  cygcheck.out attached; it might be instructive 
> to compare the
> difference between mine and yours and see if it gives us any 
> ideas why you
> get the bug and I don't.
> 
> 
> cheers, 
>   DaveK
> -- 
> Can't think of a witty .sigline today
> 
> > ### Simple Makefile Example
> >
> > CC= gcc
> >
> > OBJ= foo.o
> > FILE= foo.c
> > BIN= foo
> >
> > all: $(BIN) install
> >
> > $(BIN): $(OBJ)
> >  $(CC) -o $(BIN) $(OBJ)
> >
> > $(OBJ):
> >  $(CC) -c $(FILE) -o $(OBJ)
> >
> > install:
> >  mkdir -p ./bin/;
> >  cp $(BIN) ./bin/;
> >
> > ### End Makefile>

Above is the makefile which produced the error.  The cause seems to be cp's
handling of a .exe file.  A simple way to get what I now see as a misleading
error message from cp is:

$ touch foo.exe
$ cp foo bar# note the absence of the .exe extension
cp: `foo' and `bar' are the same file

Alan's issue arose from the fact that his makefile used a symbol for the
resulting executable and gcc naturally appends the .exe in the cygwin
environment.  When he tries to use the symbol in his cp command, the .exe is
not there and cp gives the 'same file' error message.  I did some googling
and found this issue has been mentioned in several threads.  From what I can
gather, at least one iteration of fileutils would allow making a copy of a
.exe file without using the extension, as long as another file with the same
basename and no .exe extension did not exist.

It looks like there was some code in fileutils 4.1-1 to handle .exe copies
like this, but the code was removed from the released cp in fileutils 4.1-2.

http://www.cygwin.com/ml/cygwin-announce/2001/msg00081.html 

http://www.cygwin.com/ml/cygwin/2003-04/msg00017.html




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cp.exe bug

[Ross Boulet]

> > > Problem:
> > > fileutils version 4.1-2, specifically: cp.exe does not 
> work properly.
> > >

[ ... Snip ... ]

> 
> I've narrowed it down to running `make' on my linux Makefiles, simple
> example follows:
> 
> ### Simple Makefile Example
> 
> CC= gcc
> 
> OBJ= foo.o
> FILE= foo.c
> BIN= foo
> 
> all: $(BIN) install
> 
> $(BIN): $(OBJ)
>  $(CC) -o $(BIN) $(OBJ)
> 
> $(OBJ):
>  $(CC) -c $(FILE) -o $(OBJ)
> 
> install:
>  mkdir -p ./bin/;
>  cp $(BIN) ./bin/;
> 
> ### End Makefile> 
> 
> >From prompt:
> 
> $ make
> mkdir -p ./bin/;
> cp foo ./bin/;
> cp: `foo' and `./bin/foo' are the same file
> make: *** [install] Error 1
> 
> 
> The problem I believe is that `Make' outputs the binary `foo' 
> as `foo.exe'
> which causes `cp.exe' to fail. This had previously worked 
> fine with the
> version of `cp.exe' included with `fileutils 4.1-1'
> 
> Workaround:
> Modify all existing Makefiles by adding the proper file 
> extension to the
> binary.
> 
> Example:
> BIN= foo
> 
> Should be changed to:
> BIN= foo.exe
> 
> 
> 

I cut more from my makefile and just use one symbolic in place of your BIN,
OBJ, and FILE as follows:

### Even More Simple Makefile Example

CC= gcc

FILE= foo

all: $(FILE).exe install

$(FILE).exe: $(FILE).o
 $(CC) -o $(FILE).exe $(FILE).o

$(FILE).o:
 $(CC) -c $(FILE).c -o $(FILE).o

install:
 mkdir -p ./bin/;
 cp $(FILE).exe ./bin/;

### End Makefile



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cp.exe bug

[Ross Boulet]

> Problem:
> fileutils version 4.1-2, specifically: cp.exe does not work properly.
> 
> System Info:
> Windows 2000, Cygwin DLL version 1.5.7
> 
> Reproducing from prompt:
> prompt> cp some_file ./bin/
> 
> Output:
> cp: `some_file' and `./bin/some_file' are the same file
> 
> 
> Reproducing from within Makefile:
> cp ./some_dir/some_file ./bin/;
> 
> Make output:
> cp: `./some_dir/some_file' and `./bin/some_file' are the same file
> make: *** [install] Error 1
> 
> 
> Workaround:
> Reinstall fileutils 4.1-1
> 

WFM under XP with fileutils 4.1-2 and any one of cygwin dll 1.5.7 and the
last two snapshots (20040306 and 20040312).

I can re-create the error if I create a hard link in ./bin as shown in the
second example below:

$ echo aaa >foo
$ mkdir bar
$ cp foo ./bar/

The above works fine, but the following fails with your same error:

$ echo aaa >foo2
$ mkdir bar2
$ ln foo2 ./bar2/foo2
$ cp foo2 ./bar2/
cp: `foo2' and `./bar2/foo2' are the same file

You might check to ensure there is not a link in ./bin pointing to the same
file in the parent directory.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Man not finding pages

[Ross Boulet]

> 
> You. Man. Are. Genius.
> 

Thanks, but you embarrass me.  I just get lucky occasionally.  I'm not an
expert at man and I know next to nothing about zsh, but based on some
personal observations, I think I can answer some of your questions about man
and manpath.

> Recently I posted http://article.gmane.org/gmane.os.cygwin/44906 but
> found no answer or solution. Suddenly completion started to work again
> but on the next day not even calling a single man page was found by
> man because of the wrong $MANPATH.
> 
> Now I corrected 'export MANPATH="${X11MANPATH}"' to 'export
> MANPATH=":${X11MANPATH}"' in XFree86-man.sh and now everything is
> okay.
> 
> Thanks, Thorsten
> 
> ,--- * MANPATH statements in /etc/man.conf
> | MANPATH /usr/share/man
> | MANPATH /usr/X11R6/man
> | MANPATH /usr/local/man
> | MANPATH /usr/man
> `---
> ,--- * Cygwin host (where it "doesn't work")
> | % echo $MANPATH
> | :/usr/X11R6/man:/usr/ssl/man
> | ^ see the empty path? ($manpath is "'' /usr/X11R6/man /usr/ssl/man")
> | % manpath
> | /usr/share/man:/usr/X11R6/man:/usr/ssl/man:/usr/man:/usr/local/man
> `---
> ,--- * Linux host (where it "works")
> | % echo $MANPATH
> |
/usr/share/man:/usr/local/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.
3/man:/usr/
> | X11R6/man::/opt/sun-jdk-1.4.2.03/man:/usr/qt/3/doc/man:/opt/vmware/man
> | % manpath
> | zsh: command not found: manpath
> `---
> /etc/zprofile and /etc/profile.d/zshell.zsh don't contain man
> settings. When I manually do "export MANPATH=/usr/share/man" then zsh
> does the man completion.
> 
> My questions are (I know they might not be specifically Cygwin
> related):
> 
> 1. Where and how is $MANPATH assembled?

It's a combination of things.  In my case, I run the pdksh shell.  MANPATH
is set in /etc/profile and further modified by .sh scripts in
/etc/profile.d.  It looks to me like zsh runs the same scripts as part of
/etc/zprofile.

> 2. Where does the path that the "manpath" command shows come from?

I'm not positive about this, but I believe manpath takes $MANPATH and,
assuming $MANPATH has an empty path in it, adds any paths specified in the
man.conf file, but eliminates any paths which do not actually have man
pages.

> 3. Why does $MANPATH and "manpath" output differ?

I think manpath eliminates any paths which do not actually contain man pages
(see previous answer) and adds paths from man.conf.

> 4. Why is /usr/share/man not in $MANPATH?

Because there is an empty path in $MANPATH, it is picked up from the
man.conf file.

> 5. Why is the first entry in $MANPATH empty?

>From my tests, an empty path, whether at the end or beginning or somewhere
in between (::) is what tells man to include the paths from man.conf.  If
there is not an empty path, man and manpath use only what is in $MANPATH

> 6. How and where can I fix this?

Hopefully, this is done.  HTH

> Thanks to all that can help,
> Thorsten



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cygcheck

[Ross Boulet]

> On Sun, Feb 29, 2004 at 09:36:42PM -0500, Igor Pechtchanski wrote:
> >On Sun, 29 Feb 2004, Larry Hall wrote:
> >>At 09:16 PM 2/29/2004, George Hester you wrote:
> >>>Thanks for not browbeating me.  You would be amazed at the anathema
> >>>"newbies" such as myself often generate.
> >>
> >>Yes, Igor has been known for ruining Cygwin's email list 
> reputation of
> >>being "mean".  If you're new to the list, it's an "inside" joke so
> >>don't worry if you don't get it.
> >
> >Hey, I'm workin' on it.  Give me a couple more years...  :-p
> 
> Just to be clear:  I started out mean.
> 
> I blame too much tech support at a young age.
> 
> HTH,
> cgf
> 
Was that giving or receiving too much tech support?  :-D 

I can see how either could give the same result!



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Man not finding pages

[Ross Boulet]

I solved my own problem with man not finding pages but in doing the research
on it, I found something I thought might be worthy of mentioning.  From the
message:

http://www.cygwin.com/ml/cygwin/2002-04/msg00064.html

I learned the a colon prefix to $MANPATH allows man to search its default
paths in addition to what is specified in $MANPATH.  The
/etc/profile.d/openssl.sh script handles this ok.  However, the
/etc/profile.d/XFree86-man.sh does not handle it the same way.  I had an
empty $MANPATH (since corrected by a new /etc/profile script).  The
XFree86-man.sh ran first and found no $MANPATH and thus assigned
"/usr/X11R6/man" (no colon prefix) to $MANPATH.  Then openssl.sh appended
":/usr/ssl/man".  The absence of a leading colon caused man to not find the
basic pages so that basic stuff like 'man ls' produced 'No manual entry for
ls'.

I would suggest the XFree86-man.sh script be modified to add a colon prefix
to $MANPATH to be consistent with the openssl.sh treatment of an empty
$MANPATH.

My apologies if this should have been posted to the cygwin-xfree ML, but I
thought it appropriate here because it affects more than X.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Ross Boulet]

> On Wed, 18 Feb 2004, Ross Boulet wrote:
> 
> > > On Wed, 18 Feb 2004, Ross Boulet wrote:
> > >

[...snip...]

> 
> Ok, time for "Pipes 101".  A pipe is essentially a bounded (character)
> buffer.  The producer application fills the buffer (by writing to the
> pipe), and the consumer application empties it (by reading 
> from the pipe).
> If the buffer is full, the producer application blocks 
> (inside the write)
> until room is available.  If there's no data to read, the consumer
> application blocks.  The amount of pipe data stored in memory is
> determined only by the size of the buffer.  For unbuffered pipes, the
> amount is 1 character.
> 
> Once the data is read from the buffer, its further fate is up to the
> consumer application.  Some applications (like grep) act as 
> filters, and
> require only enough memory for the current line.  Some (like 
> sort) will
> read the whole input and store it in memory before processing 
> it (or use
> temporary files internally, but these have nothing to do with the pipe
> itself).  If you're interested in the behavior of any particular
> application, I suggest you look at the sources of the corresponding
> package (available for *all* Cygwin packages).
>   Igor
> P.S. FYI, less doesn't necessarily read all of the input, and 
> has options
> limiting the amount of allocated memory.

Thanks for the enlightenment Igor,

I looked at the options for less and see what you mean.  The -b and -B
options can be used to limit how much memory less consumes.

A couple more questions - you mentioned buffered and unbuffered pipes.  What
determines whether the pipe is buffered or unbuffered?  Is cygwin managing
its own pipes, or passing them off to Windoze to manage?

Thanks,
Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Ross Boulet]

> On Wed, 18 Feb 2004, Ross Boulet wrote:
> 
[...snip...]
> > Just adding my 2 cents and hopefully to learn something:
> >
> > I know how to use pipes but I don't know how they are 
> handled "under the
> > covers".  Wouldn't piping the strace to tail or grep still produce a
> > temporary file of a large size?  I don't know if the 
> original poster is
> > concerned with disk space or only the output.  If it's a 
> space issue and a
> > temporary file is created for the pipe, I can see why he 
> would want to limit
> > the strace output directly.  If its just the result, it 
> seems tail or grep
> > would be good options.
> >
> > Ross
> 
> Pipes are direct process-to-process communication devices in 
> most (all?)
> modern operating systems.  Older systems (read: MS-DOS) 
> didn't have true
> pipes, and had to emulate them with redirection to temporary files.
> AFAIK, Cygwin doesn't use temporary files for pipes on any of 
> the systems
> that it runs on.
>   Igor
Just for my own edification and at the risk of being slightly OT

When you run:

$ foo | bar

I'm assuming the output from foo is stored in memory and then passed to bar
as the output is generated.  I deduce this from experience when I run

$ foo | less

Less starts processing the output as it comes in.  Less would obviously
require memory to store the entire output to facilitate paging back.
However, grep would be looking at each line and only keeping what its been
told.  So in

$ foo | grep sometext

Is the memory consumed by output from foo freed as soon as grep reads it and
sees that sometext is not in the output line?

Thanks,
Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Ross Boulet]

> 
> On Mon, 16 Feb 2004, Thomas L Roche wrote:
> 
> > Is there a way to limit the size of the strace output _file_, rather
> > than just the output file buffer, while preserving desired
> > information?
> >
> > I previously used strace to debug the problem that 20040213 
> induced in
> > emacs 'desktop', therefore in emacs' startup; nevertheless the
> > resulting strace.out was > 21 MB. Thus I am somewhat 
> hesitant to avail
> > myself of
> >
> > Christopher Faylor Sun, 15 Feb 2004 21:12:02 -0500
> > > more strace output for the failing condition, meaning 
> that if you do
> > > this:
> >
> > >   strace -o strace.out unzip whatever
> >
> > > it should produce a large strace file.
> >
> > (quite the understatement :-) since
> >
> > * the unzip SEGVs typically occur after 30-60 min runtime
> >
> > * I have < 5 GB free space.
> >
> > Is there a way to limit the file size directly, or to script its
> > rotation?
> >
> > Alternatively, is there a recommended mask setting that 
> will preserve
> > the desired information, while not blowing out my disk? I'm assuming
> > 'malloc' would be part of the recommended setting: anything else?
> 
> You're on Cygwin, man!  Use the scripting tools! :-)
> 
> Don't forget that strace by default sends the trace to 
> stdout.  You can
> then pipe it to any program you wish (e.g., "tail -100", or 
> "grep -v ...",
> or a whole bunch of others).  You can then redirect the 
> output of the pipe
> chain to a file, if you wish...
>   Igor
> -- 

Just adding my 2 cents and hopefully to learn something:

I know how to use pipes but I don't know how they are handled "under the
covers".  Wouldn't piping the strace to tail or grep still produce a
temporary file of a large size?  I don't know if the original poster is
concerned with disk space or only the output.  If it's a space issue and a
temporary file is created for the pipe, I can see why he would want to limit
the strace output directly.  If its just the result, it seems tail or grep
would be good options.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: What kind of executable is zcat? Crashes from cmd.exe

[Ross Boulet]

> 
> At 03:22 PM 2/12/2004, Bakken, Luke you wrote:
> >> Jamshid Afshar wrote:
> >> > I just installed Cygwin. What kind of executable is 
> >> zcat.exe? It doesn't
> >> > show up when I "dir c:\cygwin\bin\zc*" (only zcmp), but I 
> >> see it's 19
> >> > bytes in Explorer. It works fine within bash, but I want 
> >> UNIX utilities I
> >> > can use in the regular Windows Command Prompt.
> >> 
> >> $ ls -l zcat.exe
> >> lrwxrwxrwx1 rcampbel Users  19 Jan  6 17:06 
> >> zcat.exe -> gzip.exe
> >> 
> >> As you can see from the ls output, it's a symbolic link 
> >> (doesn't work in 
> >> cmd).  You can still call gunzip -c (or whatever).
> >
> >I had a similar problem when trying to use gunzip from a cmd prompt
> >outside of a cygwin shell - I was getting illegal ntvdm CPU 
> errors. The
> >fix is to replace the softlink with a hard link:
> >
> >$ cd /bin
> >/bin
> >$ ls -l zcat*
> >lrwxrwxrwx1 lukebUsers  19 Sep 21 16:29 zcat.exe ->
> >gzip.exe
> >/bin
> >$ rm zcat.exe 
> >/bin
> >$ ln gzip.exe zcat.exe
> >/bin
> >$ ls -li zcat* gzip* gunzip*
> >1125899906888251 -rwxr-xr-x+   3 lukebUsers   62976 
> Jul 23  2003
> >gunzip.exe
> >1125899906888251 -rwxr-xr-x+   3 lukebUsers   62976 
> Jul 23  2003
> >gzip.exe
> >1125899906888251 -rwxr-xr-x+   3 lukebUsers   62976 
> Jul 23  2003
> >zcat.exe
> >
> >I would suggest doing the same with any other cygwin 
> executable that is
> >a symbolic link that you intend to use "outside" cygwin.
> 
> 
> Sure, that's another option but one that eats up disk space if your 
> partition isn't formatted for NTFS.  Replacing "ln" with "ln 
> -s" in your
> examples above will get you "Windows shortcuts" which you can 
> use at the
> command prompt directly, so long as you don't mind typing 
> ".lnk" at the
> end of each linked executable.  This assumes you haven't added 
> "nowinsymlinks" to your CYGWIN environment variable of course.  This 
> approach will save the disk space on non-NTFS partitions.
> 
> 
One other caveat I have found with using hard links (on an NTFS partition)
involves upgrades.  I changed the symlink for ksh.exe -> pdksh.exe to a hard
link.  When an new version of pdksh was installed, it resulted in two non
linked files.  I had the new version as psksh.exe and the old version as
ksh.exe.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Text entry to command line program

[Ross Boulet]

> > > [...]
> > > > > Try something like:
> > > > >
> > > > > CYGWIN=notty sqlplus
> > > > >
> > > >
> > > > Is that saying notty for sqlplus and tty for everything else?
> > > [...]
> > >
> > > No, that's an interactive command line, it's not a setting of
> > > the CYGWIN
> > > variable (i.e. it's not CYGWIN="notty sqlplus"). The above
> > > actually launches
> > > sqlplus, setting the CYGWIN variable to "notty" for its process.
> > >
> > > SLao
> > >
> > Unfortunately, this does not work.  I had previously tried 
> setting CYGWIN
> > within a shell to no avail.  I found it must be set from dos before
> > launching bash or ksh.
> >
> > Ross
> 
> You could use something like 'CYGWIN="notty" cygstart -- 
> sqlplus', which
> should open sqlplus in a new window...
>   Igor
> -- 

Hmm Seems cygstart runs the application ok even without modifying
the CYGWIN variable.  This holds true for two other applications I was
having trouble with.  I had been using the native M$ telnet and ftp before I
set CYGWIN=tty for sshd.  These two display bizarre behavior with tty set.
Telnet just quits and returns to a command prompt and ftp doesn't echo
typing.  I got around this by installing the cygwin versions.  Cygstart runs
them ok as well without unsetting or changing CYGWIN.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Text entry to command line program

[Ross Boulet]

> [...]
> > > Try something like:
> > > 
> > > CYGWIN=notty sqlplus
> > > 
> > 
> > Is that saying notty for sqlplus and tty for everything else?
> [...]
> 
> No, that's an interactive command line, it's not a setting of 
> the CYGWIN
> variable (i.e. it's not CYGWIN="notty sqlplus"). The above 
> actually launches
> sqlplus, setting the CYGWIN variable to "notty" for its process.
> 
> SLao
> 
Unfortunately, this does not work.  I had previously tried setting CYGWIN
within a shell to no avail.  I found it must be set from dos before
launching bash or ksh.

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Text entry to command line program

[Ross Boulet]

> 
> Try something like:
> 
> CYGWIN=notty sqlplus
> 

Is that saying notty for sqlplus and tty for everything else?

Is there any decent documentation for what the CYGWIN variable does?

> >>
> >>
[ ... Snip ... ]
> >>
> >
> >OK, my bad.  I found a couple of references to this behavior 
> in the ML.  I
> >was suspicious of the "CYGWIN=ntsec tty" environment 
> variable (set for sshd)
> >and had tried unsetting it in the shell to no avail.  I 
> found that if I
> >unset it with dos before I start the shell, the behavior 
> reverts to what I
> >expected (password not echoed).
> >
> >What am I losing in the shell with not having CYGWIN set?
> 
> 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Text entry to command line program

[Ross Boulet]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ross Boulet
> Sent: Monday, February 02, 2004 8:05 AM
> To: [EMAIL PROTECTED]
> Subject: Text entry to command line program
> 
> 
> I've been having a problem for a while now on my XP laptop 
> with an Oracle
> program (sqlplus).  When I start sqlplus, it prompts for a 
> user id and then
> a password.  When I run it from the windows shell (cmd.exe) 
> it works as
> expected, i.e. the user id is echoed and the password is not:
> 
> c:\$temp>sqlplus
> 
> SQL*Plus: Release 9.2.0.1.0 - Production on Mon Feb 2 07:24:24 2004
> 
> Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
> 
> Enter user-name: myid
> Enter password:
> 
> 
> In bash or ksh, the password gets echoed as well (and shouldn't be):
> 
> 
> lap /home/rossboulet # sqlplus
> 
> SQL*Plus: Release 9.2.0.1.0 - Production on Mon Feb 2 07:22:35 2004
> 
> Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
> 
> Enter user-name: myid
> Enter password: mypass
> 
> 
> Its been happening to me for the last several releases of 
> cygwin but I can't
> say exactly when it started happening.  Any suggestions?
> 

OK, my bad.  I found a couple of references to this behavior in the ML.  I
was suspicious of the "CYGWIN=ntsec tty" environment variable (set for sshd)
and had tried unsetting it in the shell to no avail.  I found that if I
unset it with dos before I start the shell, the behavior reverts to what I
expected (password not echoed).

What am I losing in the shell with not having CYGWIN set?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Text entry to command line program

[Ross Boulet]

I've been having a problem for a while now on my XP laptop with an Oracle
program (sqlplus).  When I start sqlplus, it prompts for a user id and then
a password.  When I run it from the windows shell (cmd.exe) it works as
expected, i.e. the user id is echoed and the password is not:

c:\$temp>sqlplus

SQL*Plus: Release 9.2.0.1.0 - Production on Mon Feb 2 07:24:24 2004

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Enter user-name: myid
Enter password:


In bash or ksh, the password gets echoed as well (and shouldn't be):


lap /home/rossboulet # sqlplus

SQL*Plus: Release 9.2.0.1.0 - Production on Mon Feb 2 07:22:35 2004

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Enter user-name: myid
Enter password: mypass


Its been happening to me for the last several releases of cygwin but I can't
say exactly when it started happening.  Any suggestions?

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Mon Feb 02 07:08:48 2004

Windows XP Professional Ver 5.1 Build 2600 Service Pack 1

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
c:\oracle\ora92\bin
c:\oracle\ora90\bin
c:\Program Files\Oracle\jre\1.3.1\bin
c:\Program Files\Oracle\jre\1.1.8\bin
c:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\Common Files\Adaptec Shared\System
c:\util
C:\cygwin\bin
c:\borland\bcc55\bin
C:\cygwin\usr\X11R6\bin
C:\cygwin\home\rossboulet\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1006(rossboulet) GID: 513(None)
513(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1006(rossboulet) GID: 513(None)
513(None) 544(Administrators)
545(Users)1003(Debugger Users)
1007(ORA_DBA)

SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS

CYGWIN = `ntsec tty'
HOME = `C:\cygwin\home\rossboulet'
MAKE_MODE = `unix'
USER = `rossboulet'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\Ross Boulet\Application Data'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `ROSSLAP'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
EDITOR = `/usr/bin/vi'
ENV = `/home/rossboulet/.kshrc'
HISTFILE = `/home/rossboulet/.sh_history'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\Ross Boulet'
INCLUDE = `c:\borland\bcc55\include;c:\oracle\ora92\oci\include\'
JSERV = `C:\oracle\ora92/Apache/Jserv/conf;C:\oracle\ora90/Apache/Jserv/conf'
LESS = `isrR'
LIB = `c:\oracle\ora92\oci\lib\msvc\'
LOGONSERVER = `\\ROSSLAP'
MANPATH = `:/usr/X11R6/man:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLAP_HOME = `C:\oracle\ora90\olap'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0b01'
PROGRAMFILES = `C:\Program Files'
PS1 = `lap $PWD # '
SESSIONNAME = `Console'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOCUME~1\ROSSBO~1\LOCALS~1\Temp'
TERM = `cygwin'
TMP = `c:\DOCUME~1\ROSSBO~1\LOCALS~1\Temp'
USERDOMAIN = `ROSSLAP'
USERNAME = `rossboulet'
USERPROFILE = `C:\Documents and Settings\Ross Boulet'
WINDIR = `C:\WINDOWS'
WV_GATEWAY_CFG = `C:\oracle\ora92\Apache\modplsql\cfg\wdbsvr.app'
_ = `/usr/bin/cygcheck'
att = `attentus-solutions.com'
cygsetup = `c:/\$temp/software/cygwin'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
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
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd   N/AN/A
c:  hd  NTFS   28576Mb  55% CP CS UN PA FC 
d:  cd   N/AN/A

C:\cygwin  /   

RE: 'man' shows escape sequences after updating to docbook_xsl 1.64.1-1

[Ross Boulet]

> 
> * Thorsten Kampe (2003-12-29 19:48 +0100)
> > * Lynn Wilson (2003-12-23 19:40 +0100)
> >> It seems that a few months ago the man pages were showing 
> the ESC[1m etc. escape 
> >> sequences in a bash shell. The problem was quickly fixed.
> 
> >> I downloaded docbook_xsl 1.64.1-1 yesterday and the 
> problem is back.  I also 
> >> downloaded a few X-modules.  One of these modules caused 
> the 'man' problem to 
> >> re-appear.
> 
> > Same with me. Anyone with a solution (because every man page is 
> > unreadable). I haven't installed any "X modules".
> 
> Got a personal mail referring to a recent thread called "man produces
> ESC". My manpager was 'most' (which is no problem on Gentoo Linux).
> 
> export LESS=R
> export MANPAGER=less
> 
> ...in your .bashrc/.zshrc fixes the problem.
> 
> Thorsten
> 
> 

Sorry about the personal e-mail.  I meant to send to the ML.

The info in this post fixed this problem for me:

http://sources.redhat.com/ml/cygwin/2003-12/msg00565.html

Ross



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/