As a long-time Cygwin user, I can say that I would very much
appreciate as much information as possible about known good
and known bad antivirus, firewall, and anti-spyware tools or
combinations thereof, including what Windows version was used,
what special steps needed to be taken, etc.
The
Brian Dessent wrote:
$ cd $ttt
bash: cd: /cygdrive/c/Program: No such file or directory
Yes, that's wrong. [...] It's got nothing to do with
cygpath and everything to do with proper portable scripting practice.
Quite true. When you're using bash or sh, you must *quote
your arguments* if
Jim Kleckner wrote:
Dave Korn wrote:
[...]
I'm adding code to cygcheck to detect whether any of the software
that has
been known at some time to cause these kinds of problems are
installed on
the target system being cygchecked.
[...]
Do you think a tester for API sanity is possible?
i.e.
Christopher Faylor wrote:
Has anyone used this?
http://en.poderosa.org/
Looks interesting. Too bad they don't provide console emulation
to Windows.
BTW, I noticed that they include a binary version of cygterm.exe
(in Protocols/Cygterm), which links cygwin1.dll. I didn't see a
link to the
Brian Dessent wrote:
The idea behind texinfo is a format-independent way of writing
documentation. 'info' is just one of a million ways to view this same
documentation. [...]
Yes, especially for make, I've found the info files to be the best
reference, and they're easily navigable. I'm in the
Brian Dessent wrote:
With that out of the way, it's possible to get -mno-cygwin working
with gcc4
just fine, it shouldn't take any patches. You'll of course have to
build gcc
again as the MinGW version, and set up some symlinks. See the
postinstall of
the gcc package for details.
On a
Dave Korn wrote:
Hear, hear. I don't think anything so drastic as this should be
attempted
without a deprecation period of a year or so for the old behaviour.
And in
fact I think it would probably transpire to be a serious limitation on
the
utility of cygwin. Remember, if you just want
[EMAIL PROTECTED] wrote:
I am dealing with DOS text files and need to output DOS text files.
[...]
I found dos2unix, but I do not know how to properly implement it. The
following Bash code is a work-in- progress. Please let me know if a
more
efficient approach exists.
while read line
David Bear wrote:
I would like to have used something like
cd $USERPROFILE
in a bash script but since windows insists on putting spaces in
names, this seems impossible.
You might be happier writing your scripts in zsh:
bash% cd;pwd
/home/gsw
bash% export SP=silly path
bash% mkdir $SP
Christopher Faylor wrote:
When I was maintaining cygwin's gcc, I often thought about eliminating
-mno-cygwin and just providing a pure mingw cross compiler in the
distribution.
I completely agree. Anybody depending on -mno-cygwin can create
their own shell wrapper. I personally don't care so
Christopher Faylor wrote:
You haven't been paying attention, it seems.
We've already been over this ground. The performance impact
for turning on bash's automatic CRLF handling is profound.
That's why we're here.
I guess WJM around here. :-) But perhaps I've been paying more
attention than
Is there a current list of orphaned packages?
gsw
Coatimundi wrote:
Thank you for bringing this up. I forgot to mention (a sure
sign that my multitasking scaling is rolling over) that I also
tried the P option.
While this usually works, I found cases where it did not.
[...]
Since I see nothing wrong with the source and I am short on
Gary R. Van Sickle wrote:
At the risk of being over-obvious, Linux users... use Linux. In such
an insular environment, perhaps they have the luxury of only using
the One True Text File Format (whatever that is).
We're you the one who brought up Unicode earlier? Besides,
there are numerous
Has anybody successfully built subversion 1.4 (or alternately,
is a release planned soon)? It didn't build OOTB for me, and
I'd rather not duplicate effort.
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Christopher Faylor wrote:
If 'ar' insists on backslash separators that is surely a bug.
You may be right, but please stop calling me Shirley. :-)
Larry Hall (Cygwin) wrote:
Why is that? If 'LIB.EXE' will work with either and 'ar' as a Cygwin
app prefers '/', why would working with a .lib
Christopher Faylor wrote:
The dilemma here is that I read other mailing lists besides
cygwin where people are trying to use Cygwin but are close
to giving up because it is so slow. So, making bash faster
for people who are using it correctly is very desirable.
Which is why we need to get
David Rothenberger wrote:
I successfully built it with the attached patch. I haven't
actually used it yet, since some other tools I use don't
yet support 1.4, but it passed all tests except the ruby
tests.
Thanks. I'll give it a try. I meanwhile found an earlier post
that recommended
Coatimundi wrote:
If paths are included in the archive (which is typical for
libs created by Visual Studio), then ar may in some cases
claim that members (displayed with 'ar t') do not exist
when doing ar x lib.a {object} either by path/name.obj
or just name.obj.
I think you need to use the
Shankar Unni wrote:
Before sending your cygcheck.out, try checking the archives.
This problem was talked about a couple of months ago.
Thanks for the reference. The problem I reported (check the OP)
may be related but isn't exactly the same. AFAICT, suppression
of those DLL error messages
I recently ran into a problem where DLL error messages were
apparently suppressed under zsh/RXVT though they appeared
under bash/CONSOLE.
I was trying to build Subversion 1.4.0, and it at one point
configure runs the following command:
ruby -r mkmf -e 'exit(have_func(rb_hash_foreach) ? 0 : 1)'
Fabrizio Salvatore wrote:
C:\cygwin\bin\rxvt.exe -fn 7x14 -g 120x24 -si -sk -sb -sl 1000 -fg
black -bg white -T cygwin terminal Window -e /usr/bin/tcsh -l
In case you didn't know, if you some settings most of the time, you
can specify them in ~/.Xdefaults (even if you're not running X). For
Doug Irwin wrote:
One would expect a read -r fs t2 t3 to process this without
attempting to expand slashes. But I can't seem to get this bit
working... And I can't seem to find any doco on doing that in Cygwin.
I've attached the files I am testing with in the hope that someone
can help me
I wrote:
This seems to be particularly tied to ksh, and specifically
when you use to redirect a file. If you simply pipe the
output of grep to the while loop, it works. Interestingly,
sh, bash, and zsh all give the behavior you were expecting.
I couldn't resist trying it out on my Linux box,
Presumably somebody from RedHat has already contacted the ERightSoft
folks for illegally distributing cygwin1.dll cygz.dll without the
source (as part of their SUPER package).
However, they also install those files into /WINDOWS/SYSTEM32 *and*
mark them both SYSTEM and HIDDEN. This may be the
Billinghurst, David (CALCRTS) wrote:
This is not really a cygwin problem.
I guess you didn't see my post--if the compiler should be
able to find an include file in the same directory as the
source file (and/or the current directory, since they are
the same in this case), then it is a cygwin
Dave Korn wrote:
We *need* to see the actual command line.
That was in the original post (sorry, I should have made
sure it was included in the text when I CC'ed you...):
f77 -O2 -c -o jlgen.o jlgen.F
The command was being executed from the same directory
as jlgen.F, which also contains
Brad Krane wrote:
I'm trying to compile the scientific package CMBFAST-4.5.1 in the
cygwin environment using g77. I get the following error...
f77 -O2 -c -o jlgen.o jlgen.F
jlgen.F: In program `jlgen':
jlgen.F:14:
include 'cmbfast.inc'
^
Unable to open INCLUDE file
Huw wrote:
The first issue was an omission of #defines. IPv6 isn't a
necessity for the UNP source, I believe.
I'd say the real issue is a failure to protect the use of
AF_INET6. You'll notice that it's protected by an #ifdef
earlier.
The next issue I have is:
mcast_leave.c: In function
mwoehlke wrote:
(Speaking of case sensitivity, is it a Windows limitation that Cygwin
can't do this? I'm pretty sure it isn't an NTFS limitation,
as Interix has true case-sensitivity.)
You are right--NTFS can handle it, although the normal Windows
file and directory handling routines cannot.
If you need to find out what gcc is targeting, perhaps you should
use -dumpmachine instead.
$ gcc -dumpmachine
i686-pc-cygwin
$ gcc -dumpmachine -mno-cygwin
i686-pc-mingw32
Lloyd Wood wrote:
cygming, not cygwin? ('ming' is a strong insult in the UK. I get
the impression the writer doesn't
Charles Wilson wrote:
Williams, Gerald S (Jerry) wrote:
Well, it's already better than the existing rxvt in at least one way:
[...]
Well, maybe so. But sucking 100% CPU *while doing nothing*
is just not acceptable to me -- or, I suspect, to anyone else.
However, my rxvt-unicode-X package
Charles Wilson wrote:
I'm ITP'ing it as a call for assistance, and it'll remain in 'test'
state until libW11 + libXpm-W11 + rxvt-W works as well or better than
the existing rxvt in native mode.
Well, it's already better than the existing rxvt in at least one way:
Have you ever tried running
Igor Peshansky wrote:
YA typo. The above should read:
alias cs='echo -ne \ec'
Yes, this is what you need to do under BASH. I thought
I had verified it there, but I guess I wasn't getting
what I thought I was getting. (I mostly use ZSH--at
least I knew better than to write print -n $'\ec'.)
Igor Peshansky wrote:
Yes, but printf '\ec' works ju-ust fine in bash... :-)
Even better. That works unchanged in both bash and zsh.
Do you set your TERM to rxvt or xterm? The control sequence in
the terminfo database may be wrong if you don't use the native rxvt
terminal setting.
I've
Dave Korn wrote:
I generally use a line like this:
alias cls='cmd -c cls'
For me, that has to read 'cmd /c cls' or it doesn't work. :-P
This was mildly annoying me for a while as well. I finally
broke down and took a look into it. It looks like the ESC c
(reset terminal) control works
Maurício wrote:
I've been using rxvt, as recommended by chere man page. I have a
problem: in some non-cygwin console programs (ghci, the Haskell
interpreter, and others) the up arrow key doesn't work as expected.
This has been discussed here previously. Non-cygwin programs
don't recognize
Ehud Karni wrote:
[I think this discussion is off topic for cygwin]
Agreed, which is why I didn't elucidate earlier. If I
were inclined to do something like your second script
and override normal passphrase security, I'd probably
use another mechanism (maybe an environment variable?)
to avoid
Igor Pechtchanski wrote:
On Tue, 6 Dec 2005, Tomasz Chmielewski wrote:
But I don't really know where to start (which tool should I use for
it?)
Umm, crypt?
Or better yet, ccrypt. Check its manpage.
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Andrew DeFaria wrote:
Too many things? Other than I/O (which I agree is important)
of certain Windows only programs what else does rxvt do wrong?
This is getting a bit off-topic, but one thing that
bothers me is normal resizing under Windows. I'd
rather it behave like it does under X (and
Chris Taylor wrote:
Yes. Don't use the cmd-based cygwin interface.
Use rxvt.
Agreed. However, expect the occasional surprise when
running non-Cygwin console binaries since they won't
recognize that they are running on a terminal. I use
a Tcl-based debugger at work, and when running it in
Win32
Andrew DeFaria wrote:
Rxvt.font1: Lucida Console-10
Rxvt.font2: Lucida Console-13
Rxvt.font: Lucida Console-16
...
What do these do?
font sets the default font. The others set alternate fonts like the
ones you normally get on the right mouse button in xterms. At least
in my configuration,
Alireza Ghasemi wrote:
I have the same problem about ls too. Do they
ever support syntax highlighting ?
For ls, this might work for you:
alias ls='ls -color=auto '
-gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Eric Blake wrote:
Actually, a better spelling would be
alias ls='ls --color=auto'
Oops, I should have used cut and paste rather than
typing it. I meant this of course:
alias ls='ls --color=auto '
The use of a trailing space in the alias controls
whether the next word on the command line
Eric Blake wrote:
Wrong again - alias expansion in bash starts ONLY at the
first word, and only progresses on to the next word if
the current alias expansion ended in a space.
I stand corrected. In the first job where I used
ksh, they had set up aliases for everything with
the spaces at the
Corinna Vinschen wrote:
You're doing something differently here, perhaps in vim itself.
For example, the following?
:set nobackup nowritebackup
If you disable both backup and writebackup, it leaves the file
name unchanged when you write to it. So there's a workaround if
you don't care about
I started using zsh about 10 months ago myself. Now I can have
my favorite ksh feature (two argument cd) as well as all the
things I like in BASH. But I digress...
I edited my /etc/profile, replacing bash with zsh, though that
of course doesn't help me start ZSH from Windows.
To get that, I
Shankar Unni wrote:
But I think it's worth mentioning that 6.3 doesn't do this (change the
case of the name when writing back). It overwrites the old file when
writing back, thus preserving its case.
More to the point, the windows version of vim 6.4 doesn't do
this, either. So there is some
Eric Blake wrote:
I believe you are referring to the recent question about whether
cygwin services must be stopped during a WINDOWS upgrade,
My mistake. Thanks for the script.
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Eric Blake wrote:
Setup requires a reboot only when Windows reports that a file that was
being replaced was in use at the time. Therefore, if setup requires a
reboot, then you didn't properly shut down all cygwin services,
shells,
and apps.
Probably true 99.9% of the time, although couldn't
Eric Blake wrote:
Your situation isn't normal because you didn't stop all cygwin
services. While the idea has been tossed around on this list
that it would be nice if setup.exe could stop services for you,
to date, it does not. Therefore, IT IS UP TO YOU to stop services
beforehand.
Warren Young wrote:
If there is a ctags maintainer, please stand up and make yourself
known!
I've also been watching this with interest. Looking in the archives, it
appears that the maintainer listed in the ctags README file put out a
request for a new maintainer in Dec 2003. I've been waiting
Yaakov S (Cygwin Ports) wrote:
IMHO, that was not desirable. Eventually I could imagine X11 and
Cygwin native versions of the same package. I liked this method of
making the distinction.
What does Cygwin native mean? If Cygwin is meant to be a POSIX
environment, then X11 should be the
I remember seeing a question from Brian Ford about this, but
don't remember seeing any answers...
Does anyone know of a good place to post Cygwin packages? My
cable network provider gives me some space, but it's rather
small and I have other uses planned for it.
I ask because I noticed that two
Anh Vo wrote:
If you need both Ada compiler with run-time support and cygwin, do
the following.
...
3. Unzip them in cygwin installed directory. Remember to keep
the directory structure intact when Unzipping. In addition,
select over all when prompted by WinZip.
This sounds dangerous to me.
I wrote:
3. Unzip them in cygwin installed directory. Remember to keep
the directory structure intact when Unzipping. In addition,
select over all when prompted by WinZip.
This sounds dangerous to me.
Anh Vo wrote:
It is not all. What it does is to replace the Ada compiler
(GNAT) without
Christopher Faylor wrote:
I've mentioned this many times before (and suspect that
someone else is frantically typing this in right now) but
mounting directories which contain executable files with
the -X option makes things a little faster for cygwin:
mount -f -b -X c:/cygwin/bin /bin
Christopher Faylor wrote:
semaphore::_trywait doesn't have anything to do with pthread
mutexes, AFAIK.
Douglas Philips wrote:
The real issue is that Python broke with 1.5.18, either because of
the pthread change or not. Be that as it may, should I report this
bug in another forum?
Jason
Peter Waltman wrote:
since I used cygwin to implement my masters project (which I'm not
getting into publishable form),
Arturus Magi wrote:
Also, as a note: submitting a masters project may still be considered
distribution. You may want to solicit advice from a legal authority,
if
I wrote:
[...] If a disclaimer is all that you want, I'm sure you/I can get
it. In fact, as long as they know about the uncopyrighted code and
don't do anything about it, they've given up rights to it.
Christopher Faylor wrote:
And you prove that they don't know anything about it by...?
Of course we would be glad to have more people working on
the DLL (and sign the copyright assignment, sigh),
Yes, the assignment was/is a hurdle for me. It turns out to
be much easier to release something into the public domain
(at least at my company), thus my approach. I had actually
made
Christopher Faylor wrote:
But releasing something to the public domain doesn't help
Cygwin. [...] The problem is that you still have to verify
that the sources are truly public domain and how do you do
that without getting a disclaimer from a person's employer?
[...]
I truly hate all of this
I wrote:
However, it was NTFS-specific and Cygwin went a different
route (which has path length limitations, but I digress).
Christopher Faylor wrote:
And, Joshua could I get a FAQ entry about this, too? This
has got to be at least the fifth time that someone has felt
compelled to make the
Corinna Vinschen wrote:
Not that I know of. We're discussing to convert Cygwin's path
handling to use Unicode for a while now, but it will take time.
Don't expect this any time soon.
I've been off of the developer list for a while now, and
now the archives are subscriber only. :-(
How are
Christopher Faylor wrote:
Keith, you don't have a complete reference for the Nt functions do
you?
Keith Moore wrote:
So, unfortunately, I don't have a complete reference, but there are
enough islands of information around for us to piece together
everything we need.
Have you looked at
Karl M wrote:
While looking at my PATH environment variable (in response to the
recent postings about sshd and environment variables), I noticed
that . was included.
It was caused by a double ; ( a ;; sequence) in my PATH as
defined in the Windows XP My Computer Properties panel.
Yitzchak
Anh Vo wrote:
I successfully built it for three languages Ada, C, C++ with
configured as --enable-languages=ada,c,c++
--enable-threads=gnat. A number of Ada Conformance Assessment
Test Suite (ACATS) failed. Further testing reveals that the
Ada runtime tasking support was not included in
Matt Olson wrote:
I've narrowed my problems down to a relatively small test case:
[...]
Makefile:
[...]
LINKFLAGS = -g -L/lib/mingw -mwindows -mno-cygwin
LIBS = -lmingw32
foo: foo.o
gcc $(LINKFLAGS) -o foo foo.o $(LIBS)
[...]
Compiler output:
$ make
gcc -g -L.
Matt Olson wrote:
Unfortunately, while compile .o files with -mno-cygwin fixes my toy
example, it doesn't help the real code I'm trying to build:
[...]
If the problem is object files being compiled without -mno-cygwin and
linked with it, do I need to make sure that all of the (static?)
[ ] Offended. Think about the children!
[ ] Not offended. Stop bothering me with your Puritanical values.
[ ] Don't care. Can we go back to talking about how
negative this list is now?
[x] Not offended. Clean it up anyway. It's unprofessional
in the extreme and can only result
OK, anybody still reading this thread probably already knows how to
do this, but just in case, here's what you need to do to clean up
your fortune files (other than just deleting them):
First, make sure you have the tools you need and double-check that
the offensive files are in plaintext:
$ ls
Warren Young wrote:
Rebooting is a cop-out in this case. All the setup program
has to do is stop running services before starting the upgrade.
I didn't mean to imply that rebooting was the best solution,
just that there may be some extra steps involved when you do
the base Cygwin install.
One issue that sometimes pops up currently is the failure of
post-install scripts when Cygwin's DLL is being replaced. I
know that you can run into trouble if a daemon is currently
using the DLL when you update the cygwin package, at least.
Perhaps a two-part install wouldn't be that bad, as long
I've had some luck with the ECOS version. You can find
it at http://sources.redhat.com/ecos/
-Jerry
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
Dave Korn wrote:
Should it perhaps say
for d in /usr/info /usr/share/info ${INFOPATH} do
Aha! So THAT'S what happened to my info directory! I
hadn't really looked into it, since usually I just
type info bletch anyway. I ran a modified version
of that script and it's back to normal now.
BTW,
Igor Pechtchanski wrote:
However, parts of it are released under the Q
Public license, which GNU lists explicitly as
non-GPL-compatible. Does this mean an automatic
no to an official Cygwin package [...] ?
From http://cygwin.com/licensing.html:
In accordance with section 10 of the GPL, Red
On Wednesday, July 28, Scott Evans asked:
Has anyone successfully ported sz/rz to Cygwin?
I searched earlier posts, and it is clear that it had been
done. So I tried grabbing rzsz.sip from www.omen.com and
building it. No problem. Just modify the makefile to add
.exe to the executable names when
Richard Heintze wrote:
I explicitly downloaded insight seperately and had
troubles with that too, see my earler post. (gdb.exe
started the GUI interface, but it could not load the
source code file -- something to do with stat failing.
chmod 777 test.c did not help).
You shouldn't have to
Max Bowsher has graciously volunteered to take over the
maintenance of SWIG for Cygwin.
Those of you paying attention to SWIG releases may have
noticed that we haven't had one in a while. About a year
ago, I had to change jobs suddenly when my organization
was disbanded, and I haven't been able
Phil Crescioli wrote:
[...] For now I'm just curious. I have other pressing Cygwin
things to dive into before the gvim thing, but when the time
is right, I will gladly contribute to the gvim deal since I
am a very content Cygwin user :)
It's been a while since I've done it, but gvim used
G.-B. Hauck wrote:
g++ -mwindows -mno-cygwin -o test.exe test.o -L./ -lmaintest
/usr/lib/gcc-lib/i686-pc-mingw32/3.3.1/../../../../i686-pc-min
gw32/lib/libmingw32.a(main.o)(.text+0x9b):main.c: undefined
reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
This isn't
Krzysztof Duleba wrote:
I gave up. I see no chance to compile Line at all. And even
if I succeed, Line will probably bail out.
Yes, I noticed that LINE was a dead project after you
mentioned that you were trying to recompile it. I was
hoping you would have success, since it sounded like
a
Krzysztof Duleba wrote:
Why not? c code, translated to asm with -c -S on linux box,
can be later compiled and linked with Cygwin's gcc and works
fine. As you see, I have a good reason to believe that nasm's
int 0x80 will work too. So maybe I should simply look for a
nasm - gcc's assembler
Krzysztof Duleba wrote:
I wanted to test some of my linux assembler code on my
Windows-Cygwin box.
Is it possible at all?
I don't know about using BIOS calls, etc., but I've
assembled and linked a few NASM assembly functions.
I didn't use ELF format, though. There's a gnuwin32
format that
Krzysztof Duleba wrote:
What about Linux syscalls? Will Cygwin emulation layer match
it?
I just Googled int 0x80. So THAT'S what you're
trying to do. :-)
No, I think your experiment shows that Cygwin is
not emulating Linux syscalls at that level. Nor
would I have expected it to.
On the other
I linked swig (unchanged from swig-1.3.19-1) against
cygwin-1.5.0-1 and it still works (no surprise).
I'm not sure if we should really bother updating it,
since it has no other DLL dependencies and the old
version should therefore continue to work.
I created a 1.3.19-2 version just in case. It's
Corinna Vinschen wrote:
Packages which depend on external libs should be newly build only
if all external libs have been newly build first. E.g. vim depends
on ncurses. So I, the vim maintainer, will wait with creating a new
vim version until Charles, the ncurses maintainer, has
Christopher Faylor wrote:
Rebuild your package.
Run it.
+Does it work?+
/ \
No. Yes.
See if it
I've updated the version of SWIG to 1.3.19-1. Tarballs should
be available on the Cygwin mirrors shortly.
As per the SWIG web page (http://www.swig.org):
SWIG (Simplified Wrapper Interface Generator) is a software
development tool that connects programs written in C and C++
with a variety
A new version of the SWIG package (swig-1.3.19-1) is ready for upload from
the following locations:
Binary: http://home.ptd.net/~gwilliam/cygwin_swig/swig-1.3.19-1.tar.bz2
Source: http://home.ptd.net/~gwilliam/cygwin_swig/swig-1.3.19-1-src.tar.bz2
Or follow the links from:
Randall R Schulz wrote:
Obligatory disclaimer: I ANAL. You?
You'd better make that IANASCJ
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:
91 matches
Mail list logo
