RE: Best AVS to use with cygwin
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 problem with the BLODA is that any tool that periodically updates itself can become dodgy, and similarly can fix itself in the future. And even if it's still dodgy, I'd want to know what to look out for. For example, I don't necessarily care that McAfee was known to be dodgy at one point. We used it at work (so I didn't have a choice anyway), although I haven't noticed problems with Cygwin because of it. Or at least if I have had any problems, I didn't know enough to know whether McAfee was the culprit. For home use, I have been able to find most of the popular all-in-one packages for free with various rebates: CA, Norton, McAfee, Kaspersky, Panda, etc. And I have boxes of them just waiting to be tried out. :-) But you know what? I don't really want to be spending my time doing this. I'll gladly try one or two out, but not all. And given the choice, I'd rather use something that's pay-once-and-your-done (or better yet free-as-in-free) than something that's free-for-a-limited-time. One of the reasons I use Cygwin is because I don't want to put up with that type of Windows nonsense. Stuff should just work, right? So from my POV, the more information, the better. It's less that I have to discover on my own. - Taking my own advice, here are my experiences: (For anti-spyware, I run Spybot and Ad-Aware, in addition to whatever is in the suite I happen to be using. I'll also run clam periodically, though not nearly as often as I should.) I used a corporate McAfee Antivirus subscription for years, with good success. That's not to say that I've never had any problems with Cygwin programs (e.g., I have at times seen an out of resources type error), although I haven't had any particular reason to blame McAfee for it. We've switched to Symantec AntiVirus in the last year or two, and so far I haven't had any problems with it, either. We have a hardware firewall that our IT folks like to rely upon. I've also used ZoneAlarm with good success. At home, I've used both ZoneAlarm and Sygate (which I believe was now acquired by Symantec). The latter seems easier for a novice to install/maintain (and is what I'm currently using), although both have worked well for me. With ZoneAlarm, I had to spend more time approving Cygwin applications to run, from what I remember. I've used multiple versions of McAfee's all-in-one product. The 60-day to 1-year subscriptions that came prepackaged with my new PCs seemed more sluggish and CPU-intensive than the boxed versions I tried. I'm not sure why. Currently I have one system using only McAfee Antivirus along with Sygate (and Spybot/Ad-Aware/etc.) and this has been pretty stable, though it's now one of my less-used systems. One product I would recommend against is CA Internet Security Suite. My laptop came with a free all-in-one trial (I think it was Norton Internet Security), and although I never noticed any problems with Cygwin, for some reason I didn't feel very happy with the product. I installed a free-with-rebate version of CA Internet Security, and while I haven't noticed any Cygwin problems, it seems to interfere everywhere else. It's privacy feature will even cause the PC to blue screen if you open up a particular web page (in any browser)--and I'm not talking about one of *those* web pages: this one's on a Boy Scout site! Its firewall also is way to intrusive with web surfing, messing up many legitimate sites. All of my experiences are currently with Windows XP, although all but one of the systems started with Windows 2000. I just bought two new computers with Vista (one of which may actually remain a Vista machine), so I'm in the market for a new set of internet security solutions. -Jerry -- 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: cygpath -u doesn't seem to convert spaces properly
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 they could possibly contain spaces or other word separators. So learn to do it. Seriously, take a few minutes and try it: $ mkdir a b c $ ABC=a b c bash: cd: a: No such file or directory $ cd $ABC ... etc. If you don't want to have to quote variable expansions all the time, use another shell. I know that zsh, at least, doesn't require you to quote them. That being said, you still should learn how to quote in a regular POSIX shell. Portable shell scripts should really start with #!/bin/sh, after all. -gsw -- 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: Help needed with Big List of Dodgy Apps
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. make some known good calls and assert their return values or some such. Is there a common way that the badly designed hooking dlls cause problems or is each one quite different? Yes, this would be very useful alone or in combination: Detected current or previous Frobulator AV installation: Some versions have been known to interfere with Cygwin. Checking for known problems caused by this software... No known interferences have not been detected, although if you run into any of the following symptoms, you should start by *completely uninstalling* the suspect software and trying again (simply disabling it will likely not correct the problem): ... The problem with an Embedded Big List of Dodgy Apps is that any software that automatically updates itself could at any time suddenly start or stop interfering. Warning: you are running Windows, so it is likely that there is at least one Dodgy App hanging around somewhere. Please reboot and reinstall everything. gsw Every program has at least one bug and can be shortened by at least one instruction - from which, by induction, it is evident that every program can be reduced to one instruction that does not work. - Ken Arnold -- 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: Interesting looking terminal emulation for cygwin
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 Cygwin sources used to build it, though. gsw -- 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: Looking for man pages
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 mildly tolerate
category for the info viewer, however. I mostly use tkinfo (easily
googled) to browse info files.
However (bringing the discussion back on-topic for the list), I had to
make some tweaks to tkinfo to get it to run properly under Cygwin. The
main issue was with the commands used to automatically decompress info
files. Cygwin implements zcat and gunzip as shell scripts, and (for me
at least) the Tcl interpreter didn't handle them properly. I've been
assuming this is because wish isn't really a Cygwin executable.
Anyway, you simply need to change the value of tki(compresscat-*) to
use gzip -d -c rather than zcat/gunzip. The following shows what I
changed for TkInfo version 2.8:
$ diff -u orig/tkinfo-2.8/tkinfo tkinfo-2.8/tkinfo
--- orig/tkinfo-2.8/tkinfo 2004-03-22 19:56:39.0 -0400
+++ tkinfo-2.8/tkinfo 2007-08-08 12:23:36.85625 -0400
@@ -562,9 +562,12 @@
set tki(self) [info script]
set tki(timestatusB) 0
set tki(iconic) 0
-set tki(compresscat-Z) zcat
-set tki(compresscat-z) gunzip -c
-set tki(compresscat-gz)gunzip -c
+# set tki(compresscat-Z) zcat
+# set tki(compresscat-z) gunzip -c
+# set tki(compresscat-gz) gunzip -c
+set tki(compresscat-Z) gzip -d -c
+set tki(compresscat-z) gzip -d -c
+set tki(compresscat-gz)gzip -d -c
set tki(compresscat-bz2)bunzip2 -c
set tki(rawHeadersB) [option get . showheaders Showheaders]
set tki(showButtonsB) [option get . showbuttons Showbuttons]
I also found that it helps to customize the Tkinfo settings in your
.Xdefaults file. In particular, the default fonts looked pretty bad
for me in Cygwin. Here's how I set them:
Tkinfo*font:{Tahoma} 9
Tkinfo*Text.font: {Lucida Console} 12
-Jerry
--
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: GCC 4.1.1
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 related note, is Cygwin's MinGW cross-compiler still switching to the more Gnu-ish convention (i.e., called as i686-pc-mingw-gcc and without -mno-cygwin)? 4 or 5 months ago it sounded like such a change was imminent. We already build i686-pc-mingw-gcc and friends for Linux. I've been debating whether I should build Cygwin versions (or more likely create shell wrappers), which would allow us to transition later without changing our makefiles. If this isn't happening anytime soon, I'd favor building my own to wrappers. (If it's not happening at all, I'd stick to -mno-cygwin.) gsw -- 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: .exe magic
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 Linux on windows, you'll get a much better emulation by installing a VMware machine, and it's faster too. A lot of Cygwin's 'added value' comes from interoperating in a single unified environment. I don't think I'd go that far. If you want to run prepackaged Cygwin utilities from Windows, you could add . to PATHEXT. (If you're building the utilities yourself, you can simply add the .exe extension.) If for some reason that isn't sufficient, you can use some flavour of links (preferably NTFS hardlinks) to give you .exe versions of the Cygwin executables. The people that would be most put out are those of us that use Cygwin-based shells by default. Every time we run a native Windows executable, we'd need to tack .exe onto it (at least until we've set up a symlink or alias). Of course, we have the same situation now for .bat files and such, it's just not as common. (I'd rather have some flavour of PATHEXT magic than .exe magic anyway, but I'm certainly not going to bring *that* up.) :-) :-) :-) In any event, I almost never get to the end of a program name before typing [Tab] on the command line (so I see the .exe's anyway), and I'd appreciate having an easy way to distinguish Windows executables that aren't going to appreciate my nifty Cygwin paths... gsw -- 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: Using dos2unix and attaching it to a while loop
[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
do
i=0
echo LINE - $line
echo i - $i
MP3[i++]=$(awk '/^.*\.mp3/ { print $1}')
CRC[i++]=$(awk '/^.*\.mp3/ { print $3}')
echo MP3[i] - $MP3[i]
echo CRC[i] - $CRC[i]
done (dos2unix $FILE)
#do some stuff then
unix2dos $FILE
The cygwin console returns the following error. My syntax is not
correct.
FileRenamer3.sh: line 132: syntax error near unexpected token `'
FileRenamer3.sh: line 132: ` done
(dos2unix $FILE)'
There are many problems with that code snippet. I'll start by answering
your question:
-
Yes, that format is incorrect. I think perhaps you are confusing the
$(...) operator, although that's not really what you want either.
dos2unix FILE converts the file in place, so to use that form you
would simply do this:
dos2unix $FILE
while read line
do
...
done $FILE
unix2dos $FILE
If you want convert the contents of $FILE without changing the file
in place, you could use dos2unix as a filter as follows:
dos2unix $FILE | while read line
do
...
done
-
I also noticed that i is reset to zero on each pass, then incremented
in a presumably incorrect manner. This code sets MP3[0] and CRC[1] on
each pass, then tries to print ${MP3[2]} and ${CRC[2]}. I'm reasonably
certain that you also don't want to run awk quite the way you're doing
it--perhaps you meant to do something like $(echo $line | awk ...)?
Finally, $MP3[i] doesn't access array elements, nor does it expand
the value of i--I think you meant ${MP3[$i]}. But as you said it is
a work in progress...
-
gsw
Disclaimer: I rarely use BASH myself, although I do quite a bit with
ZSH (because I can), KSH (because I have to), and SH (because we all
ought to). :-)
--
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 spaces in environment vars
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 # Note the quotes
bash% cd $SP # Oops, forgot to quote!
bash: cd: silly: No such file or directory
bash% exec zsh# Make it a one-way trip :-)
zsh% cd $SP
zsh% pwd # Hey, it worked!
/home/gsw/silly path
Or get used to always using quotes when you use a variable
that could possibly contain a space. Trying to pre-escape
environment strings for bash gets messy real quick.
Yes, I know the real problem usually comes when you try to
build command lines in environment variables. You need to
separate parameters without splitting paths. You can do
this in ZSH as well, either by forcing the old behavior as
needed (through expansion options and/or eval, along with
built-in support for basically what you're asking for) or
by using better array-based methods:
zsh% cd;pwd
/home/gsw
zsh% command=cd ${(q)SP} # try (qq)/(qqq)/() also
zsh% echo $command
cd silly\ path
zsh% eval $command
zsh% pwd
/home/gsw/silly path
zsh% cd;pwd
/home/gsw
zsh% command=(cd $SP)
zsh% $command # no eval needed
zsh% pwd
/home/gsw/silly path
gsw
--
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: Eliminating -mno-cygwin from gcc?
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 much about a deprecation period, as long as it explodes noisily and points me in the right direction three years from now when I try to run an old build script that happens to use it. Big projects really shouldn't be using -mno-cygwin, anyway--the preferred way to do it is to install MinGW compilers and either use MSYS or change your Cygwin path to put MinGW's tools first. How complete of a cross chain were you thinking about supporting? I only installed the compilers and my MinGW bin contains over 60 unique executables--that could mean a fair number of i686-mingw-* programs created (consider GNAT for example). gsw -- 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: Similar Bash 3.1.18 CR/LF Problem
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 you think. If a patch is incorporated into upstream BASH, it's not going to cause performance problems. If it did, it would be rejected. That's something for the upstream maintainers to decide. I may be coming at this from a different angle, to be sure. I'm not really interested in a Cygwin-specific solution--I don't particularly want the ability to write scripts that can't run under Linux. gsw -- 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/
Orphaned packages
Is there a current list of orphaned packages? gsw
RE: Re: Does 'ar' work with native MS Windows libs?
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 time, I am going to chalk this up to an unidentified mistake on my part, unless I see it again and have time to build bintools myself and step through the code in debug. You've probably already ruled this out, but if you do see it again, you might want to verify that you're not mixing path separators (LIB.EXE will use either). I believe you must use only backslash-style separators if you want to interoperate with ar. gsw -- 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: Bash and CR/LF line-endings
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 situations where files get transferred with CRLF without needing to involve Windows, so stray CR characters occasionally show up here and there. I'm sure many of us would like support for CRLF endings on Linux as well. gsw -- 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/
Subversion 1.4
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 Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Does 'ar' work with native MS Windows libs?
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 produced by 'LIB.EXE' containing '\' separators make 'ar' work better? Perhaps ar doesn't prefer either. It strips the directory name when you add files. It does tolerate directories in the form that LIB.EXE would normally generate (i.e., with backslashes). Yes, it is still arguably a bug if ar cannot handle files that LIB.EXE can produce, although there may be a reason. It's been a while since I looked into the internals of archive files, but I vaguely remember that slashes have a special meaning when found in archive directories. gsw -- 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: Similar Bash 3.1.18 CR/LF Problem
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 the patch in upstream. If you can't make it faster, you can at least make what you're comparing against slower. :-) Seriously, I'd have a hard time believing that supporting CRLF endings would noticably impact performance if it were done as part of upstream BASH. Special-casing Cygwin (especially when you start doing things like checking for DOS paths, examining the first line, etc.) would impact performance, surely. So I agree--don't do that. gsw -- 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: Subversion 1.4
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 ./configure --disable-shared for a previous version. This does allow my build to complete, although I get many errors from make check: [...] Running all tests in target-test.py...success Running all tests in getopt_tests.py...FAILURE Running all tests in basic_tests.py...FAILURE Running all tests in commit_tests.py...FAILURE Running all tests in update_tests.py...FAILURE Running all tests in switch_tests.py...FAILURE Running all tests in prop_tests.py...FAILURE Running all tests in schedule_tests.py...FAILURE Running all tests in log_tests.py...FAILURE Running all tests in copy_tests.py...FAILURE Running all tests in diff_tests.py...FAILURE Running all tests in export_tests.py...FAILURE Running all tests in externals_tests.py...FAILURE Running all tests in merge_tests.py...FAILURE Running all tests in revert_tests.py...FAILURE Running all tests in stat_tests.py...FAILURE Running all tests in trans_tests.py...FAILURE Running all tests in autoprop_tests.py...FAILURE Running all tests in blame_tests.py...FAILURE Running all tests in special_tests.py...FAILURE Running all tests in svnadmin_tests.py...FAILURE Running all tests in svnlook_tests.py...FAILURE Running all tests in svnversion_tests.py...FAILURE Running all tests in utf8_tests.py...success Running all tests in history_tests.py...FAILURE Running all tests in lock_tests.py...FAILURE Running all tests in cat_tests.py...FAILURE Running all tests in import_tests.py...FAILURE Running all tests in svnsync_tests.py...FAILURE Running all tests in authz_tests.py...FAILURE Running all tests in changes-test.exe...success [...] gsw -- 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: Re: Does 'ar' work with native MS Windows libs?
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 -P option:
$ ar t foobar.lib
release\foo.obj
release\bar.obj
$ ar xv foobar.lib 'release\foo.obj'
no entry release\foo.obj in archive
$ ar xvP foobar.lib 'release\foo.obj'
x - release\foo.obj
gsw
--
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: DLL error messages suppressed under zsh/RXVT
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 should be universal. I got error messages (due to DLL rebase issues) in one case, but not in the other. Worse, the program simply hung rather than returning an error code (which the makefile would have caught, at least). My WAG is that the fact that RXVT isn't a Windows console was the cause of the differing error message suppression that I saw, but as Peter Castro pointed out, perhaps all bets are off when there are rebase issues. I am still confused about Peter's ability to get a dialog box. Is this a version difference? Is there a new CYGWIN option? I'm getting error code 53 (ENOANO ?!?) if a DLL is missing. BTW, I didn't see any response to Dave Korn's August 30 comment on the missing DLL issue. Did I miss it? Are we looking for a P to TC? Dave Korn wrote: Of course, but there's still an issue here why this case doesn't get a proper ENOENT status in $? and an error message on stderr. gsw -- 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/
DLL error messages suppressed under zsh/RXVT
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)' This never returned since mkmf#have_func() was hanging due to a rebase issue (at least rebaseall resolved it). The problem is, I didn't get any error messages. I normally run zsh under rxvt, invoked as this Windows shortcut: C:\cygwin\bin\run.exe rxvt -ls -e zsh -l -i I was eventually able to get some warning messages about the inability to load certain DLLs when I switched to a bash shell invoked in a standard console window invoked as this Windows shortcut: C:\cygwin\bin\bash.exe --login -i Unfortunately, I didn't save the messages, and of course I don't get them anymore now that I've rebased. I'm assuming that the messages were going straight to the console, which is why they didn't show up under RXVT, although I could be wrong. Does anyone have any idea how I can get error messages like this while running zsh under RXVT? gsw -- 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: How to run rxvt
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 example, -sl 1000 becomes Rxvt.saveLines: 1000. gsw -- 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: Read not honouring -r?
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 work this out. No doubt I have missed something rather obvious. -r has nothing to do with it: CR/LF line endings are the culprit. 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. So for the short term, run d2u on filesystems.cfg. If you plan to continue using ksh, you may want to follow up and try to understand the discrepancy--there may be an option that allows you to get the behavior you want (and if not, it may be worth having KSH's behavior changed to be more consistent with other shells, but that's something for the maintainer and/or upstream KSH support to decide). gsw -- 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: Read not honouring -r?
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, which runs the same version of pdksh as my Cygwin install. Even more interestingly, it works as you were expecting on Linux as well. So this looks like a problem with the Cygwin port of pdksh. This simpler test case demonstrates it pretty clearly: --test.sh-- dos2unix foo.txt while read x; do echo $x; done foo.txt unix2dos foo.txt while read x; do echo $x; done foo.txt --foo.txt-- 1 2 3 Run under various shells: $ sh test.sh# zsh and bash yield same result foo.txt: done. 1 2 3 foo.txt: done. 1 2 3 $ ksh test.sh # this one fails for DOS endings foo.txt: done. 1 2 3 foo.txt: done. 1 $ _ gsw -- 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/
3PP: SUPER/ERightSoft
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 cause of some of the duplicate cygwin1.dll errors that have been reported. If you look in their forum pages, the author basically says Everybody do that--you don't like, you don't use. (What he doesn't say is that uninstalling SUPER leaves your system unable to play many AVI files since cygwin1.dll isn't the only system file that the installer blindly copies and/or trashes.) Anyway, I'm not entirely sure why, but SUPER seems to be getting at least some good press, so this is likely to become more of an issue in the future. Is there anything that can be done that would really discourage them? (I suppose a bunch of us could attempt to reason with them, but the author doesn't seem to be a reasonable person.) gsw -- 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: Fortran Compiler Error CMBFAST
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 problem (even if it's an upstream problem, the maintainer should report the GCC bug and eventually build a new cygwin version). The compiler can't find the file cmbfast.inc. Perhaps: - copy the file into the same directory as jlgen.F, or - point to it with the -I compiler directive The first doesn't work. The latter does, but the question is whether -I. should be required or not. gsw -- 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: Fortran Compiler Error CMBFAST
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 the include file that it cannot find. Adding -I. to the command line fixes the problem. The OP didn't provide enough information about where the files resided, but I downloaded the CMBFAST package myself and verified that ./configure make results in the same error. I also verified that it builds if you manually compile with -I. (or add -I. to FFLAGS in the makefile). Is everyone in this thread aware of the effects of -I- [...] I assume that's not relevant since -I- is not used. It needs to be pointed out that adding -I. doesn't help any if you aren't building in the source dir but a parallel object dir... True. This was a workaround for this specific case. In general, you would want to use -I$(SRCDIR) or something along those lines, although technically I don't think you should need to do either. :-) -- I just recreated the problem with some minimal code, and got some more information in the process: Create a file foo.for that contains one line: include 'foo.inc' Create an empty file named foo.inc in the same directory. Copy foo.for to foo.f, foo.FOR, and foo.F and try to compile all four of them from that directory: $ f77 -c foo.for# runs OK $ f77 -c foo.f # runs OK $ f77 -c foo.FOR# runs OK $ f77 -c foo.F foo.F:1: include 'foo.inc' ^ Unable to open INCLUDE file `foo.inc' at (^) $ _ So it seems that the rules by which the preprocessor looks in the current directory and/or the directory containing the source file does not apply to files named *.F for some reason. It's possible that this was intentional, although I don't get this behavior on my Linux box (which granted is using GCC version 3.2.3, so it could have changed since then...). gsw -- 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: Fortran Compiler Error CMBFAST
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 `cmbfast.inc' at (^) Tim Prince wrote: Normally, you would specify the path to search for include files with -I, if it is not in the current working directory. I looked at the library, and the referenced include file *is* in the same directory. The library even includes a configure script, so this isn't simple pilot error--it looks like there is a bug in the compiler. For now, you can work around the problem by adding -I. to the command lines, or more likely to the end of FFLAGS in the Makefile (after running ./configure). I don't use FORTRAN enough to say whether the behavior we are seeing is correct, though from the evidence I've seen I'd say it isn't. gsw -- 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: UNIX Network Programming (unpve13e) make failing (AF_INET6 undeclared).
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 `mcast_leave_source_group': mcast_leave.c:78: error: storage size of 'mreq' isn't known I don't know anything about the ip_mreq_source structure, but it looks to me like the current version may be having general issues with support for various platforms and configurations. Have you tried using the version at www.kohala.com (i.e., unpv12e)? That was the the last one that Richard Stevens wrote. At least the lib directory seems to build OK for me. Even if you really want the latest library, looking at the older code may help you with the port. I haven't looked into the new version of that book, but the new authors certainly had big shoes to fill. gsw P.S. www.kohala.com seemed to have intermittent access problems (at least for me), so be patient. -- 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: Re: Handling special characters (\/:*?|) gracefully
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. Managed mounts deal with the problem by encoding the actual names stored in the underlying file system. I experimented with this approach at one point, but didn't like the issues caused by using up to 3 characters to represent each character in the path name. The last I checked, there were still some 256-character limits floating around in Windows (at least in the non-Unicode APIs). I haven't looked into the current solution--perhaps it deals with this in a way I didn't consider. Another approach would have been to provide replacements for certain Windows library functions that use native NT functions internally to get around the limitations. I believe the total list of needed replacements is: CopyFile CopyFileEx CreateDirectory CreateDirectoryEx CreateFile DeleteFile FindFirstFileFindFirstFileEx GetFileAttributesGetFileAttributesEx GetFullPathName GetLongPathName GetShortPathName GetBinaryType MoveFile MoveFileEx MoveFileWithProgress RemoveDirectory ReplaceFile SearchPath SetCurrentDirectory SetFileAttributes SetFileSecurity FindFirstChangeNotification Of course, this would have been an NT-specific solution. I actually use a version of such a library to create some of the otherwise-uncreatable files in a /dev directory (which is not on a managed mount). That way, I can do: $ ls /dev audio com3 kmemsda1 tty18 tty3 tty41 tty53 tty8 ttyS5 auxcom4 lpt1sr0tty19 tty30 tty42 tty54 tty9 ttyS6 cdrom com5 lpt2ttytty2 tty31 tty43 tty55 ttyS0 ttyS7 clipboard com6 lpt3tty0 tty20 tty32 tty44 tty56 ttyS1 ttyS8 com1 com7 lpt4tty1 tty21 tty33 tty45 tty57 ttyS10 ttyS9 com10 com8 mem tty10 tty22 tty34 tty46 tty58 ttyS11 ttym com11 com9 nulltty11 tty23 tty35 tty47 tty59 ttyS12 urandom com12 con pipetty12 tty24 tty36 tty48 tty6 ttyS13 windows com13 coninporttty13 tty25 tty37 tty49 tty60 ttyS14 zero com14 conout ptmxtty14 tty26 tty38 tty5 tty61 ttyS15 com15 console random tty15 tty27 tty39 tty50 tty62 ttyS2 com16 dsp scd0tty16 tty28 tty4 tty51 tty63 ttyS3 com2 fifo sda tty17 tty29 tty40 tty52 tty7 ttyS4 gsw -- 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: Geomview Cygwin setup
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 like cygwin.)
You think that's bad? When the company I was working for spun off
from ATT, they decided to name themselves loo scent. :-) I must
admit I'd never heard of the UK ming until you mentioned it. I
suspect we at least pronounce it differently, though.
gsw
--
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: rxvt-W
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 seems to work well with aafire. I didn't mean to imply that it was ready to use, but it is encouraging. I recently noticed the libaa performance problem with Cygwin's RXVT, so I was eager to see how your package fared. -Jerry
RE: rxvt-W
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 aafire -driver curses under RXVT? Both in native and X mode, Cygwin's rvxt is horrendously slow. I've seen this with some other libaa-compiled apps as well--they'll tie up 100% of the CPU and get very little accomplished. gsw
RE: Clearing the COMPLETE screen.
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'.) In fact, under a Command window it looks like this may end up working the same as the clear command (for me it does at least clear the scroll contents). But if you use RXVT (as I do), sending ESC-c does a much better job than clear. At least I did say YMMV. :-) gsw P.S. It could also be written 'echo -e \ec\c', which has an odd alliterative appeal (to me). :-) -- 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: Clearing the COMPLETE screen.
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 tried both rxvt and xterm. Either way, it doesn't clear the contents of the scrollback buffer. Looking a bit deeper, the terminfo and termcap clear/cl entries for both term types are \E[H\E[2J, so it's doing the same thing, I think. gsw -- 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: Clearing the COMPLETE screen.
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 under both RXVT and standard Command windows. It resets the scrollbar in addition to clearing the screen. So I just changed my clear screen alias to: alias cs='echo -n \ec' YMMV, of course. gsw -- 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: Question about rxvt
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 that they're connected to a terminal window. If this is important to you, you may have to start them in a command window. Here's one of the many ways to do it from a Cygwin shell: cmd /c start MYPROG gsw -- 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: encoding scripts (so that user can't see passwords easily)?
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 the passphrase appearing in the process list. But as we both said, this discussion is really OT for this list. gsw -- 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: encoding scripts (so that user can't see passwords easily)?
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: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Re: font
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 command
windows do under Windows), jumping to even multiples
of lines columns. I use a tiny zsh script to clean
up (with the added benefit of allowing you to resize
via command line):
-CUT-
#!/usr/bin/zsh
# Resize RXVT window to an exact number of LINES COLUMNS
#
# Usage:
# fs [LINES] [COLUMNS]
#
# Where LINES or COLUMNS may be:
#
# number- specify exact value
# (+|-|*|/)number - value relative to current setting (+1, /2,
etc.)
# anything else - use current setting (current text region)
#
# 'fs' by itself trims the current window to exactly match its text
region
#
# E.g.:
# Trim to fit text: fs
# Set width to 132: fs . 132
# Set to 24x80: fs 24 80
# Add one line: fs +1
# Double the width: fs . '*2' # must quote '*' from the shell
case $1 in
+[0-9]*|-[0-9]*|\*[0-9]*|/[0-9]*) ((L = $LINES $1)) ;;
[0-9]*) L=$1 ;;
*) L=$LINES ;;
esac
case $2 in
+[0-9]*|-[0-9]*|\*[0-9]*|/[0-9]*) ((C = $COLUMNS $2)) ;;
[0-9]*) C=$2 ;;
*) C=$COLUMNS ;;
esac
print $'\e[8;'$L;${C}t
-CUT-
gsw
--
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: font
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 console mode under RXVT, I don't get a prompt. If that's not an issue for you, go ahead and don't look back. BTW, you can specify Windows-style fonts for RXVT in your .Xdefaults file. For example, here are the RXVT options in my .Xdefaults file: Rxvt.geometry: 120x50 Rxvt.saveLines: 1000 Rxvt.backspacekey: ^? Rxvt.meta8: true Rxvt.font1: Lucida Console-10 Rxvt.font2: Lucida Console-13 Rxvt.font: Lucida Console-16 Rxvt.font3: Lucida Console-19 Rxvt.font4: Lucida Console-22 Rxvt.font5: Lucida Console-25 Rxvt.font6: Lucida Console-28 Rxvt.color4:lightblue3 Rxvt.background:rgb:3f/1f/1f Rxvt.foreground:PapayaWhip Rxvt.color12: SteelBlue Rxvt.color15: PapayaWhip Rxvt.scrollBar_right: true Rxvt.scrollstyle: next (I don't know whether the quotes are recommended or not. At least on my system they're not needed, but I've seen other posters use them.) gsw -- 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: Re: font
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, shift-keypad-plus and shift-keypad-minus cycle through these fonts (the default font is at position 2.5). gsw -- 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: syntax highlighting in vim
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: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: syntax highlighting in vim
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 will also be subject to alias expansion; True, but I prefer not to make assumptions about how people are using aliases. The space at the end of the alias makes it behave like the unaliased ls in that regard. -gsw -- 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: syntax highlighting in vim
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 end (including ls and cd) and added convenient aliases for some parameters. Even though I've long since abandoned the use of aliases for parameters, I've been keeping the spaces at the end of my aliases thinking it was more flexible. That's it. I'm ditching the spaces. gsw -- 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: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
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 those features. :-) -- Looking at the source, I think I found where VIM adjusts for pseudo-case-sensitive file names: the fname_case() function modifies the file name to match an existing file if present. The function is defined in os_win32.c and os_msdos.c but not in os_unix.c. There is also a USE_FNAME_CASE macro to protect calls to it. Simply defining that macro and function isn't enough, since it is used in the os_mswin.c version of mch_FullName(), but not it the version in os_unix.c. But it looks like a conditional call to fname_case() could be added to the end of the UNIX version, since this construct appears elsewhere in common code. You'd most likely want to use a Cygwin-specific implementation of fname_case() that doesn't convert slashes into backslashes, honors mount points, etc. gsw -- 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: zsh as login shell
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 copied the Shortcut created by Cygwin (the one that runs BASH) and changed the Target to: C:\cygwin\bin\zsh.exe -l -i -l is login -i is interactive (I suspect you don't need it) Although I probably have an unjustified aversion to adding layers of BAT-file abstraction. The mkzsh tool does sound easier. gsw -- 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: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
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 code in there somewhere that knows about case-wacky-pseudo-sensitive file systems (OK, it probably just has #ifdef WIN32 around the old method, but still...). gsw P.S. It might be possible to come up with a workaround using some trickery within VIM (e.g., do an ls on the dirname of % via event hook when you open a new file and either rename % somehow or hook into the file write event). -- 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: SETUP: In-use files have been replaced
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: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
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 it also be possible that another Windows program is opening a Cygwin file in a mode that prevents deletion? (I haven't tried it, but I wouldn't be surprised to get this message if you're viewing a directory that is being uninstalled.) Herb Martin wrote: So what is the method to teach Setup that the file has been updated. Have you tried simply uninstalling the Cygwin package? If you installed the new one into another location, you presumably don't need or want the other one. For most packages at least, SETUP doesn't automatically try to update it if you haven't installed it. gsw -- 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: SETUP: In-use files have been replaced
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. Thanks. I remember one of the Cygwin major contributors indicating that (s)he didn't find the need to stop the Cygwin services first, but perhaps I misunderstood. gsw -- 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: ATTN: ctags maintainer
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 for Corinna to formally put packages up for grabs before volunteering, but this is one of the packages I depend on as well. I've never actually built ctags, so I wasn't in a rush to volunteer for that package anyway, but I'm keeping an eye on a few others. ;-) -Jerry
RE: Consensus about man and doc X11 directory structure
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 standard for GUI apps. I won't argue the point (since I'd like to see better X11 support), but POSIX doesn't necessarily imply X11 support. However... What about console apps? When I was still using the X11 version, my /usr/X11R6/bin/vim linked in X11 libs, although /usr/bin/vim didn't. That way, vim -g did the right thing. And from a practical standpoint, notice my wording there. It's true that various inconveniences and performance issues eventually caused me to move away from using X for daily Cygwin work, though I used to use it almost exclusively. Perhaps X11 improvements could draw me back, but until they do I'd actually prefer a few more Cygwin-aware GUI apps that don't use X. I wouldn't mind grabbing these apps from /usr/win32native or whatever, but that doesn't change the fact that (at least at this point) X11 isn't for everybody. gsw
Free/cheap FTP/HTTP hosting for packages?
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 of my must have packages are currently ownerless, along with some others that would be a real shame to lose. The conditions that caused me to hand over SWIG maintainership have changed, so I'd be willing to consider maintaining some packages if need be. gsw
RE: Tasking not implemented on this configuration
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. Doesn't it interfere with other Cygwin compilations? Plus, I wouldn't expect this version of the compiler to create Cygwin executables (e.g., that would understand Cygwin paths, etc.). If not, why interfere with the Cygwin installation at all? I took the approach recommended at mingw.org and installed it into C:/MinGW. Then I created a script that would put it in the beginning of my path when I wanted to use it. You could do this automatically if you only want the MinGW version. A search of the mailing list doesn't reveal any messages from the maintainer containing the word tasking both task and ada. Perhaps the question should be restated with a subject of GCC-ADA: or Attn: gcc-ada maintainer? -Jerry -- 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: Tasking not implemented on this configuration
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 tasking run-time support with the that does. Every thing else remains the same. Perhaps, but I personally wouldn't want to blindly overwrite parts of my compiler system. Even if I were going to install it in the Cygwin area, I'd remove the old one with setup.exe and then unzip WITHOUT overwrite. I put some thing like Ada compiler or GNAT on the subject. It was quite a while ago. If you search my name, Anh Vo, you may have seen it. I remember seeing and responding to the following one: http://sourceware.org/ml/cygwin/2005-05/msg00408.html although that didn't mention either in the subject. gsw -- 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/
mount -X and FAQ (was RE: Cygwin build system SOOOO SLOOOWWWW ???)
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 Finally got around to trying that one, but it broke the tkinfo (Tcl/Tk) script I use regularly. Some experimenting revealed that I had to add the following to make it work: mount -f -b -x c:/cygwin/bin/wish84.exe /bin/wish84.exe mount -f -b -x c:/cygwin/bin/wish84.exe /usr/bin/wish84.exe and presumably I'd also want: mount -f -b -x c:/cygwin/bin/tclsh84.exe /bin/tclsh84.exe mount -f -b -x c:/cygwin/bin/tclsh84.exe /usr/bin/tclsh84.exe The FAQ (http://www.cygwin.com/faq/faq_3.html) mentions using this idiom for strace and cygcheck, but not for Tcl/Tk. Perhaps these should be noted as well? gsw -- 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: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
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 Tishler wrote: No, this is the right mailing list. However, you can increase the probability of it getting fixed by helping to isolate the problem. Besides submitting a patch, a minimal C test case is the best way to go. Please ignore this if it sounds like noise, but I thought at least Jason might be interested. I wasn't following this thread closely since rebaseall had been mentioned, but the semaphore/pthread/Python mix wakened an old memory that I thought I should bring up. Give me a minute while I crank up the old wayback machine... :-) 3 or 4 years ago I introduced a patch into Python thread support that used native semaphores if they are supported. The POSIX way to indicate this is to define _POSIX_SEMAPHORES in a header file, but at the time either Cygwin either didn't define it, defined it in some way differently, or its definition was ignored for some reason (I don't remember the exact details). It was frustrating to me since the reason for my change was to fix Python threading under Cygwin, which was broken at the time, and although the Python developers accepted my change, they would only allow: #ifdef _POSIX_SEMAPHORES and not: #if defined(_POSIX_SEMAPHORES) || defined(__CYGWIN__) Fortunately, somebody else fixed the pthreads threading bug in Cygwin (the lack of an assignment prevented me from doing so), so things progressed without my help. Anyway, I just looked into /usr/include/sys/features.h, and _POSIX_SEMAPHORES is now defined. If we are seeing errors that indict semaphore::_trywait, it seems likely that my code is now being used, although I know that it wasn't being used when I first introduced it into Python. However, features.h does not appear to have changed in a while (at least not according to its comments). :-P Did something change (either in Cygwin or Python) that could explain why Python would have started recognizing that Cygwin supports POSIX semaphores? If so, perhaps that is contributing to the error. I'd poke around myself, but it's been a while since I've been inside either Python or Cygwin internals. On the other hand, I verified at the time that the semaphore solution worked under Cygwin Python, so I wouldn't expect it to be a problem even if the change just took place. However, it could potentially help in isolating the problem. -Jerry -- 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: how do I cite cygwin for academic publication?
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 possible. Is it possible that we can give Peter some advice that doesn't require contacting a lawyer? :-) How about this: Peter, are you saying that your executables will never leave your PC? Even if so, you may want to cover yourself by keeping all of the sources, including the source to Cygwin, together with the executables. It may even help you at some point in the future. Personally, I'd download the source to everything that I needed (e.g., Cygwin, GCC, etc.) and package the whole thing so it can be easily stored and/or transferred to new media as needed. gsw -- 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: Unicode in filenames support? (FAQ update needed)
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...? Realistically, probably an e-mail from somebody in the legal department (just not necessarily a signed document). Or you could force the issue by sending a certified letter referring to the files on SourceForge. :-) It'd be a shame if you aren't able to use public domain files due to legal concerns. I thought taking the high ground by entirely dropping the copyright would maximize usefulness to everybody. gsw -- 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: Unicode in filenames support? (FAQ update needed)
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 some progress with the assignment, but it went back to ground zero when my old group was disbanded. but what you wrote sounds somewhat like a special solution which requires lots of new if (is_ntfs) tests, roughly. Sort of, although I approached it as a set of services that could replace Windows file operations with extended versions that could be selected dynamically. I had come up with the following list of functions to replace (which perhaps might be of some use to you): CopyFile CopyFileEx CreateDirectory CreateDirectoryEx CreateFile DeleteFile FindFirstChangeNotification FindFirstFile FindFirstFileEx GetBinaryType GetFileAttributes GetFileAttributesEx GetFullPathName GetLongPathName GetShortPathName MoveFile MoveFileEx MoveFileWithProgress RemoveDirectory ReplaceFile SearchPath SetCurrentDirectory SetFileAttributes SetFileSecurity gsw -- 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: Unicode in filenames support? (FAQ update needed)
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 assignment stuff that is required for contributions to FSF programs and Cygwin. I think it's time for someone to come up with an online way to do this. My employer authorized the release into the public domain, making the code explicitly not protected by copyright. The lawyer-types don't trust the assignments though, so online forms therefore wouldn't help anyway. 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. Of course, IANALATEIHSMBSI (http://cygwin.com/acronyms/#IANAL and http://cygwin.com/acronyms/#YANALATEYHSMBSI). gsw -- 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: Unicode in filenames support? (FAQ update needed)
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 observation that the current implementation of managed mode has path length limitations. Sorry, poor wording choice. To be honest, I don't even know if managed mounts still have those limitations since I don't use them, although that was my understanding at the time. My approach was to use underlying NT services that bypass normal Windows naming restrictions, allowing more or less arbitrary Unicode strings as file names. It had path length limitations, but they were no worse than what Windows has already. It was my understanding that Cygwin managed mounts did this by escaping such characters into multi-character sequences, which of course would cause you to run into the Windows limits sooner. There are other ways to accomplish this, so the mechanism may have changed for all I know. (I don't necessarily expect that there will be any interest in my solution, but I thought that I should mention it just in case. As I said, there are other ways to deal with this without imposing path length limitations, and I don't even know how much of a concern such limits are in general.) gsw -- 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: Unicode in filenames support?
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 you thinking about doing this? At one point, I created a framework that supported this. Unicode support was actually just a side-effect--my real goal was to let you use two files whose names differ only by case or use files with otherwise illegal names such as aux. I even went so far as to create a project on SourceForge so that I could release it into the public domain. However, it was NTFS-specific and Cygwin went a different route (which has path length limitations, but I digress). I did finally get my company's permission to release the code, but there was little point by then. (I also had to scramble to survive a reorg at that time and didn't have any time at all for quite a while afterwards.) If there is interest in my NTFS-specific solution, please let me know. (Actually, it's not necessarily specific to NTFS, though it probably is in practice. It definitely doesn't support FATxx or Win9x.) gsw -- 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: Serious performance problems (malloc related?)
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 ReactOS (http://www.reactos.com)? They're doing a Windows NT port from scratch. It's not quite the source to Windows, but it's a valiant attempt to duplicate it. I've sometimes found it useful for finding out about some of the more obscure interfaces or for understanding the behavior of the documented ones. Of course, I'd still start at http://msdn.microsoft.com (and probably some of the well known Undocumented Windows sources) first. gsw -- 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: Re: PATH oddity
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 Scott-Thoennes wrote: This has been discussed here before; IIRC (and I may not), the . is the equivalent of what windows does. An empty entry in the windows path (;; in the middle or ; at the beginning or end) makes it search the current directory. If that is the meaning under Windows, it would be meaningless in practice since Windows searches the current directory first. However, under bash (and other shells that I'm familiar with) an empty entry is the same as .. I guess it depends on your POV, but being able to specify the current directory in your Windows PATH, even though it is only meaningful under Cygwin, could be a useful feature. gsw -- 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: Building GCC-4.0-20050430
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 the build. OT for this list, but you may be interested to know that the MINGW version supports Ada tasking. I haven't delved into it, but the GNAT manual indicates that Ada tasking support is pretty simple if you have a minimal amount of POSIX support. Of course, you discovered that it doesn't quite work OOTB. Since I was just toying around when I ran into this, I found it easier to just install MINGW. Personally, I don't see the point in supporting Ada if you don't support tasking, but maybe that's just me. :-) Of course, PTC. -Jerry -- 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: Cannot link ___assert, __impure_ptr with -mno-cygwin
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. -L/home/matt/lib -L/lib/mingw -o foo foo.o -lmingw32 -mwindows -mno-cygwin I don't quite know how you got that makefile to produce precisely that output. :-) Regardless, try starting again after removing foo.o. My guess is that you have a version of foo.o compiled without -mno-cygwin. If you rebuild everything, it should compile cleanly, although I expect it will still not act the way you want it to. If you run it from the console you won't see any output. Try removing the -mwindows option. I don't think you need the -L/lib/mingw or -lmingw32 options either, although they shouldn't hurt. -Jerry -- 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: Cannot link ___assert, __impure_ptr with -mno-cygwin
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?) libraries I link with are also compiled with -mno-cygwin? Yes, that's no doubt what's going on. You are trying to link some object files that depend on the Cygwin runtime library and others that depend on the MinGW library. If you can, you should choose one or the other entirely, which should resolve your link issues. If you're looking for some way to link some libraries that depend on Cygwin and others that depend on MinGW, I have no experience with that. -Jerry -- 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: Obscene content in cygwin file.
[ ] 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 in embarrassment and trouble. Definitely rot13 them and make them -o. I'd rather fortune was kept as a complete package rather than using a separate package for the offensive stuff. If you want to create another package with just tame stuff, that's OK. Maybe it should be called enutrof. Or sbeghar. :-) Make sure you rot13 fortune2-o while you're at it. It's currently in plaintext, even though you need to specify -o or -a to add it to the fortune list. I just rot13'd fortune2-o and limerick (i.e., limerick-o) on my work machine. I can't afford to have stuff like that lying around for corporate snoops to find. gsw -- 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: Obscene content in cygwin file.
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 /usr/sbin/strfile /usr/sbin/strfile $ which tr /usr/bin/tr $ cd /usr/share/fortune $ head -3 fortunes2-o limerick == fortunes2-o == Would you please have another look at my nose and put in that cocaine stuff -- Adolf Hitler, quoted by Dr. Giesing in Nuremberg trial == limerick == A bad little girl in Madrid, A most reprehensible kid, Told her Tante Louise Then to properly encode and mark the offensive files as such: $ cd /usr/share/fortune $ mv fortunes2-o fortunes2-o.orig $ mv limerick limerick-o.orig $ rm fortunes2-o.dat limerick.dat $ tr A-Za-z N-ZA-Mn-za-m fortunes2-o.orig fortunes2-o $ tr A-Za-z N-ZA-Mn-za-m limerick-o.orig limerick-o $ /usr/sbin/strfile -x fortunes2-o $ /usr/sbin/strfile -x limerick-o $ rm fortunes2-o.orig limerick-o.orig gsw -- 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: setup.exe sucks
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. Other things that come to mind are making sure that mount points and accounts are set up. This could be done as a separate step that does whatever it needs to do in order to prepare for the package installer and then kicks off the package installer. The package installer could then be a regular Cygwin application. This would also make it easier to replace the package installer component in the future. -Jerry
RE: setup.exe sucks
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 as the base Cygwin installer automatically kicks off the package updater and the package updater can kick off the base Cygwin installer when needed/requested. The base Cygwin installer could then be done using MSI or whatever and could initiate reboots/etc. as needed before starting the package updater. gsw
RE: looking for an arm9 cross-compiler
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: http://cygwin.com/faq/
RE: INFO Death
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, you need to add colons to your IFS or replace
them (e.g., $(echo $INFOPATH | sed -e 's/:/ /g')).
And, of course, /usr/info and /usr/share/info were
already in my $INFOPATH anyway.
Thanks,
-Jerry
--
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: Packaging O'Caml
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 Hat permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL. IANAL, but the Q Public License is listed on the OSI web page, so there don't appear to be any legal restrictions-- some Cygwin packages use different open source licenses already. Or have there been policy changes for new Cygwin packages that I'm not aware of? -Jerry
Re: zmodem port?
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 calling ln. I attached the diff -c output so you can patch it. This adds a new cygwin target. Actually, testing it was more complicated than I expected. In the end, I set up sshd and used zssh (downloaded from sourceforge). In fact, zssh comes with another flavor of rz/sz that builds just fine via ./configure make. -Jerry Williams makefile.diff Description: makefile.diff -- 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: Where is the gnu/cygwin GUI Source code debugger?
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 download insight separately, since it is part of the gdb package (as Arturus Magi pointed out). As Chris Faylor pointed out, use the command insight (assuming it is properly installed). -Jerry -- 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/
swig: New package maintainer
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 to get back to it since. So thank you, Max! Have a virtual beer on me! -Jerry Williams
RE: GVIM
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 to build pretty well out of the box for Cygwin. The catch (at least it was a catch at the time) was that it was the X11 version. For a while I maintained five flavors of VIM executables: Cygwin's official VIM, an X11 GVIM (really just a link), an X11-aware VIM, a Windows VIM, and a Windows GVIM. Today I use the Windows version of GVIM and the official Cygwin non-GUI version of VIM. However, since I last built gvim for Cygwin, the Win32 native X11 window manager has been added to Cygwin, and handling for paths from outside of Cygwin has been improved (e.g., \cygwin\bin\vim \autoexec.bat from a Command Prompt). So it might be worth reinvestigating. But perhaps what you really want isn't the X11 version at all, but a Cygwin version with a Windows interface. This might be preferable to reduce the interdepencies that otherwise could arise, since gvim is normally just the equivalent of vim -g (i.e., Would regular Cygwin VIM have to become X-aware? Would there be two separate programs called vim? etc.). Just some food for the curious. :-) -Jerry -- 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: WinMain in an own static lib - _WinMain@16 undefined reference ?! ;.(
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 specific to Cygwin. Modules are only pulled from a library if something else refers to them (the underlying MINGW run-time reference doesn't count!). Try adding [EMAIL PROTECTED] to the command line. -Jerry -- 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: Assembler
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 worthwhile project. Either way, by trying to get LINE working, you should now have a better idea what it would take to create a system that emulates int 0x80 syscalls. However, my own code already can change int 0x80-like system calls to appropriate function calls [...] This is more efficient anyway, since the int 0x80 traps would probably be making the same calls anyway. I wanted to try out my app with some deassembler, but I haven't found anything interesting. Which one do you use (in Linux)? I don't do much X86 disassembling (most of my assembly coding is in ARM or DSP), but I would start with ndisasm (the nasm disassembler). -Jerry -- 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: Assembler
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 translator? int 0x80 is part of Linux, not nasm. In fact, nasm was generating the int 0x80 instructions just fine--they simply don't work under Windows. So such a translator wouldn't help. Cygwin does a great job translating many of the system calls, but these are invoked via function calls, not Linux internal software interrupts. By asking for int 0x80 support, you're really asking for the ability to run precompiled Linux applications. Googling brought me to http://line.sourceforge.net, which may be more along the lines of what you seek. -Jerry -- 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: 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 works with Cygwin. I've only ever linked them as functions called via the C environment, but if you take the following: ; standalone.asm section .text extern _printf global _main _main: pushebp mov ebp,esp pushdword [value] pushdword format call_printf add esp, byte 8 leave ret segment .data value dd 0x87654321 format db 'Should be 87654321: %0lx',10,0 and assemble, link, and run it as follows: nasm -f gnuwin32 standalone.asm gcc standalone.o ./a.exe It does the right thing. :-) -Jerry -- 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: Assembler
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 hand, you can get at DOS functions, at least if you build your executable correctly. For example, the following: ; hello.asm [ORG 0x100] section .text global _start _start: mov ah,9 mov dx, hello int 0x21 mov ax,0x4c00 int 0x21 section .data hello db 'Hello, World', 13, 10, '$' can be converted into a .COM file and run via: nasm -o hello.com hello.asm chmod +x hello.com # to avoid Permission denied ./hello.com Is there a way I could force Cygwin's ld to work the way Linux ld used to? I don't know about that, but you can specify the entry point explicitly: ld -e _start hello.o -Jerry -- 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/
swig-1.3.19-2 test results (ready for upload???)
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 at http://home.ptd.net/~gwilliam/cygwin_swig/experimental/swig-1.3.19-2.tar.bz2 and http://home.ptd.net/~gwilliam/cygwin_swig/experimental/swig-1.3.19-2-src.tar .bz2 I also created a setup.hint for the experimental version (it should be replaced with the original one once cygwin-1.5.0-1 is released). It's at http://home.ptd.net/~gwilliam/cygwin_swig/experimental/setup.hint gsw
Re: HEADSUP package maintainers: Welcome to Cygwin 1.5.0
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 created a new ncurses version. Sorry if this question sounds dense, but can you please clarify something for me: Is waiting until all dependent libraries really enough, or should VIM and it's DLL dependencies all be brought forward lock-step? I'm sure whether something fails will depend on whether it actually used those features, but once ncurses has been updated, is it possible VIM won't work until it's been updated as well? If so, this would mean you'd need to coordinate the upgrade of cygintl-2.dll and cygiconv-2.dll at the same time, right? $ cygcheck vim.exe Found: .\vim.exe Found: C:\cygwin\bin\vim.exe vim.exe .\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll .\cygintl-2.dll .\cygiconv-2.dll .\cygncurses6.dll Use -h to see help about each section $ _ If so, is running cygcheck against all of your executables and DLLs (if not already used by your executables) enough to identify all of your dependencies? Or is there a more preferred way? For packages on auto-pilot that just pull in whatever configure tells them to, it would be nice to make checking such dependencies as painless as possible. gsw
RE: HEADSUP package maintainers: Welcome to cygwin 1.5.0
Christopher Faylor wrote: Rebuild your package. Run it. +Does it work?+ / \ No. Yes. See if it relies on DLLs or libraries Send announcement to which export an interface which cygwin-announce. has changed. Will do next week, once I'm back on a fast network. Static libraries don't concern me, since all I'd need to do is notify the maintainer and wait until a new one is ready. DLLs could be more problematic if updating one of them can cause my package to stop working. That's why I asked if cygcheck is enough to identify all of my DLL dependencies. gsw
Updated: swig-1.3.19-1
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 of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk, Ruby, Guile and MzScheme, however the list of supported languages also includes non-scripting languages such as Java and OCAML. SWIG is most commonly used to create high-level interpreted programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG may be freely used, distributed, and modified for commercial and noncommercial use. Version 1.3.19 is a regular development release of SWIG. More information, including release notes and user documentation, can be found in the directory /usr/doc/swig-1.3.19/. ***LATE-BREAKING NEWS*** One thing that won't be currently found in that directory is an issue that has come up with the latest Cygwin release of Perl (5.8.0), which uses 64-bit integers. This results in some warnings of the following type when compiling the output of SWIG: warning: cast to pointer from integer of different size It is specifically caused by the SWIG_ConvertPtr() function, which casts Perl type IV (now a long long) into a pointer in several circumstances. This warning does not appear to cause any test cases to fail. This issue just came up and is being addressed by the SWIG development community. -- Gerald Williams Cygwin SWIG maintainer *** INSTALLATION *** To update your installation, download and run setup.exe using the Install Cygwin now link at http://cygwin.com/. SWIG is in the 'Devel' category. Questions or comments? First check the FAQ and Cygwin mailing list archives at http://cygwin.com/lists.html (you may want to sign up for the list as well). Then mailto:[EMAIL PROTECTED] *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED]
swig-1.3.19-1: Ready for Upload
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: http://home.ptd.net/~gwilliam/ -Jerry Williams
RE: Big Brother is Real
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: http://cygwin.com/faq/
