Workaround for broken pipe key on 98/ME
Hi Folks, I just installed cygwin on W98 and hit the problem with the pipe key on W98/ME: http://cygwin.com/faq/faq_5.html#SEC129 After googling to see what had already been tried, it became clear that the problem was with readline. This workaround uses readline to fix itself. Just add the following line to your ~/.inputrc "¦":"|" In case that got mangled in transmission, or you can't display 8-bit characters, you should be able to do this: $ tail -1 ~/.inputrc | xxd 000: 22a6 223a 227c 220a ".":"|". (although if you got it wrong, you won't be able to pipe into xxd ;-) This gets readline to map the broken pipe into the solid pipe. Because of the difficulty in entering this on a system where you can't enter pipes, might I suggest that the following (slightly more pedantic) lines are added to the default inputrc file? # If you are running Windows 98 or Windows ME and cannot enter pipe # characters in the command shell, remove the hashes from the # following three lines. #$if term=cygwin #"¦":"|" #$endif The FAQ could then be amended to direct people in the direction of ~/.inputrc. Alternatively, (does anyone actually need broken pipes?), the default behaviour could be to perform the mapping and to instruct users who want the broken pipe to comment out the mapping. HTH Phil ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** -- 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: Updatedb grinding floppy drive
Dai Conrad wrote on Monday, February 27, 2006 1:05 AM:: > I've been having a problem with updatedb for a while now. The > symptoms are that late in the process it starts grinding my A: drive > and I have to hit ctrl-C to kill it. > ... > > Any suggestions or recommendations will be greatly appreciated. I don't know what find is up to, but you're unlikely to want to have A: in your locatedb, so your first stop should be: $ man updatedb and search for "prune". It pays to tune your locatedb generation to suit your own system. Due to mount points, files are likely to appear several times in the database if not tuning is performed, which is pretty wasteful (both in terms of disk space, and the amount of time and disk thrashing spent indexing the same directory tree multiple times). Unless you need locate to show you all possible ways to refer to a file, you can reduce the database redundancy using a combination of --prunepaths and --localpaths. E.g. my crontab runs something like the following: /usr/bin/updatedb --localpaths="/ /c" --prunepaths='/c/cygwin /cygdrive /a /d /usr/bin /usr/lib' You can read this as: - Index / (i.e. C:\cygwin) and C: (mounted on /c) - Omit /c/cygwin as that's already covered by /. - Omit /cygdrive because that would access other filesystems. - Omit /a and /d (mountpoints for my floppy and DVD drives respectively). - /usr/bin is mounted as /bin and /usr/lib as /lib, so there is no point in indexing either /usr/bin or /usr/lib because they're already covered by /bin and /lib. HTH Phil -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the H.E Information Systems Ltd. Tel:0161 866 9066 Web: www.heis.co.uk This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- 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: Precision of doubles and stdio
Roberto Bagnara wrote on Monday, March 06, 2006 9:30 AM:: > > what is and what is not noise depends on the application. > In our applications we systematically use controlled rounding on IEEE > 754 floating point numbers. In the end, what we obtain (in memory) > are definite (i.e., provably correct) lower or upper bounds of some > quantities. > > Call `x' such a quantity, and suppose we have that our computed upper > bound for `x' is the IEEE 754 Double Precision number > > 0x4051b99a, > > that is (exactly!), > > 70.905684341886080801486968994140625. > > If that number is (wrongly!) printed as > > 70.90568434188608080148696899414 > > then we lose correctness, since > x <= 70.905684341886080801486968994140625 > does not imply > x <= 70.90568434188608080148696899414. > So, the final "0625" is not "noise" in our applications: > it is what may make the difference between a correct statement and an > incorrect one. > I'm absolutely amazed that you are a professor of computer science! If I had written software that relied on the _exact_ meaning of the least significant digit of a floating point number (either at university, or at work), I would have been the subject of ritual humiliation! You should NOT be using floating point numbers for such an application. Floating point numbers are _approximate_ representations of the continuous number series that shares the same approximate value. That the IEEE format is an integer multiplied by some power of two is an implementation detail. Floating point hardware is frequently not 100% accurate in the LSB of the mantissa due to internal rounding errors and the datasheets will often tell you so. That being said, the thing which completely floors me is that you are relying on behaviour which is clearly beyond that given in the language specification. This is one of the most rudimentary mistakes in programming. Frankly, this is beyond belief for someone in your position. C doubles are accurate to 16 or 17 decimal places, if you expect 48 significant figures then you deserve all the bad results you get. That you should then choose a public forum (and the wrong one at that!) to complain about this is astounding. Ask yourself this: if your brain surgeon uses an axe, will the inquest find the axe at fault or the surgeon? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the H.E Information Systems Ltd. Tel:0161 866 9066 Web: www.heis.co.uk This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- 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 copy/paste behavior
On Tuesday, February 08, 2005 6:14 AM Rizwan Kassim wrote (sort of): > I haven't been able to find out how to do the following: > I'd like to accelerate my car using the left pedal and find some > other way of stopping it (maybe the pedal on the right). > > Anyone know how to do this? > > Cheers, > Rizwan It may be possible, but if you do it, don't be surprised when you crash and burn the first time you try to drive a different car. The selection model used by rxvt is standard throughout the X11 world. Learn it and enjoy the elegant simplicity of the scheme instead of the insane mouse, keyboard, mouse, keyboard routine that characterises the Windows way. Phil ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** -- 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 copy/paste behavior
On Tuesday, February 08, 2005 7:25 PM Dave Korn wrote: > It's insane. > > Unless you have the precision muscular control skills of a world-class > gymnast, a mouse always moves at least a little bit when you press down on the > button. Which is one reason why I prefer a trackball - moving and clicking are independent operations. They take a bit of getting used to, but after the first day or so, you stop trying to shove it around your desk. Once you've got used to it, the mouse seems very clumsy. I also found that my RSI and back problems disappeared, but YMMV. > This makes it very tricky to select a new window without unintentionally > erasing the contents of the clipboard that you were hoping to paste there > because the mouse moved just enough as you clicked it to select a single > character and the auto-copy destroyed your clipboard contents without asking. I use focus-follows-mouse (aka X-mouse) so no clicking is required. > Destroying user data without any kind of confirmation, are-you-sure, or > requiring a difficult-to-type-accidentally key-combination (such as ctrl-c) is > an appallingly incompetent piece of UI design. It's like having a pistol > without a safety catch, or an ICBM without a dual-key control. A fair point. > FWIW, it's not just X programs that do this. TeraTerm (a 'doze terminal > emulator) One reason I use it ;-) > And don't tell me... I wouldn't dream of telling the great Dave K anything! ksh saved my sanity back in the days when it was just csh or sh. > ...that I'm only ever allowed to select windows by clicking on > the menu bar and that I get what I deserve if I click in the main part of the > window. If you have lots of windows open, the menu bars of many of them are > often obscured. Why should 99% of the window's surface area be verboten for > selecting that window? Again, focus-follows-mouse (and auto-raise if you like that sort of thing - I don't) WFM. > The entire model is screwy. It wastes lots of my time and interrupts my > workflow. The 'doze way works smoothly and is much closer to fail-safe: it's > very hard to accidentally press Ctrl+C and lose data in the same way. Equally, I waste lots of time going back to the original window because I forgot to press ctrl-C. > Real experts... avoid using the pointer altogether? > ...operate a computer with one hand on the mouse and one on the > keyboard *at the same time* anyway. OK, now you're just showing off! I guess it all boils down to personal preference in the end. Until the telepathic HCI comes along (RSN), we'll all struggle to communicate our intentions computers from time to time. Even then, I'm not sure that I would really appreciate a computer that obligingly uninstalled all Microsoft programs every 5 minutes! Phil -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: What is this
>Brian Dessent wrote: >"Mirko Tebaldi (Indirizzo Pubblico)" wrote: >> >> What is /bin/test.exe ? >> >> i have a script that uses that, but it has not output and no --help >> or --usage !!! >Have you considered "man test"? FWIW, this should always be the FIRST thing one tries (or "info test"). It's a REALLY bad idea to execute a program to try to find out what it does. Suppose that "test" was an acronym for "Trash Entire System Thoroughly", and suppose that it ignored the command line. Oops! There goes your C: drive! The --help options to commands should only be used when you already know what the command does, but are unsure what parameters it takes. Here endeth the lesson. -- Phil Betts ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** -- 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: Bash is very, very stable (was: Bash returns incorrect process status)
Pierre A. Humblet wrote: > Hi Phil, > > The symptoms are consistent with the pid reuse issue, > although it is not common on NT4, AFAIK. > > A patched version is available as > http://xx.xxx.xxx//bash.exe > Please keep that url private. > > If you try it, let me know (or the list) the outcome. > > Pierre Hi Pierre, WFM. I've given it a quick test using a command-line grabbed out of my history that always went wrong unless I used /bin/echo. I'll install it in place of the regular bash now so that it'll get a thorough work-out. If there are any problems, I'll keep you posted. Nice work, Phil ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** -- 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 is very, very stable
Hi Eric, Eric Hanchrow wrote: > Did you see the patch at > http://cygwin.com/ml/cygwin/2004-09/msg00882.html? I predict it will > fix your problem. I had seen it, but at the time I hadn't drawn the connection between the symptoms I was seeing and those the patch addressed (and which I hadn't experienced). After my posting, Pierre contacted me privately to point me in the direction of a patched exe which does indeed fix the problem. Thanks for your input. Phil ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** -- 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: stupid spaces in environment vars
David Bear wrote on Friday, February 09, 2007 4:56 AM:: > Okay, the problem is in quoting in shell scripts, I think. It is. It's not a Windows problem and it certainly isn't a cygwin problem. Although spaces occur more often in Windows than on other platforms, they can and do occur on Unix/Linux for example. Any properly written shell script must be written with the assumption that a path contains spaces. If they aren't, at best they are broken, at worst they are a security risk. If you're going to write shell scripts, learn to do it right. Learn the quotation rules, by which I mean both knowing what they are and UNDERSTAND them. Windows is only making you more aware of the issues because so many important paths include spaces. (Quite why anyone would *want* to create a path with spaces in it, particularly important paths, is beyond me, but then MS does a lot of dumb things) -- Phil Linux: enough rope to hang yourself Windows: a ready made noose conveniently placed around your neck -- 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: Accessing remote PC (ssh?)
zzapper wrote on Thursday, March 15, 2007 3:34 PM:: > zzapper <[EMAIL PROTECTED]> wrote in > news:Xns98F49BF615AA2zzappergmailcom@ > 80.91.229.5: > >> >> I used http://pigtail.net/LRP/printsrv/cygwin-sshd.html as FAQ >> > # basic steps > setup a windows password (if you have none) > mkpasswd -cl > /etc/passwd > mkgroup --local> /etc/group > ssh-host-config (answer various questions, I specified same password > as windows) > net start sshd > # remote PC > ssh [EMAIL PROTECTED] > > > -- > zzapper > http://SuccessTheory.com/tips/ vim, zsh & success tips I don't mean to be rude, but do you hear voices in your head? The reason I ask is because, after being told that you'd answered your own question, you seem to have embarked on a strange one-sided conversation with yourself, where you appear to be telling yourself what you did, as if you didn't know already. Not only that, but you've demonstrated to the list that you haven't been paying attention to external stimuli, because only this week the source of your guidance was decried on this list as being a source of dubious advice with a history of causing problems, yet you still used it. -- 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: Accessing remote PC (ssh?)
Dave Korn wrote on Thursday, March 15, 2007 4:50 PM:: > On 15 March 2007 16:28, Phil Betts wrote: > > [talk list snipped, no need to x-post] > I didn't cross post, I set the reply to field to the talk list. I just forgot to point out it was TITTTL'd. > It's considered good netiquette that if you post a problem to a > list, and later find a solution, you post a followup saying what the > solution was, http://cygwin.com/acronyms#FTR. That way, any time > someone has the same problem again and stumbles across your post in > the archive, they'll be able to find the solution with it. I agree totally, but the given "solution" was to a question that hadn't been posed. Rather it was a response to his own post about how he'd worked out (by reference to a very recently decried site) how to implement your answer to the original question, which (as you pointed out) he'd already answered himself in the subject line of the initial post. Although my attention has now lapsed somewhat, it appears from the continuing thread that I was right to flag up, albeit in an oblique manner, that the "solution" given was perhaps not of the highest provenance. -- 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: Extraneous characters in mutt text manual?
Mark S. Reglewski wrote on Friday, March 23, 2007 4:50 PM:: > Forgive a naive question from a naive user: should there be any > formatting codes/escape sequences at all to work around in what's > supposed to be a plaintext file? > /usr/share/doc/mutt-1.4.2.2/manual.txt gives this as it's last line: > "This document was written in SGML, and then rendered using the > sgml-tools package." Haven't the utilities used to render the > plaintext file from its SGML source left unwanted gunk in this > instance? This file is not meant to be a plaintext file. It is meant to be read using the F1 key from inside mutt. /etc/Muttrc sets up the F1 key to invoke less. You may find that there are a few non-ASCII characters which are shown as e.g. . If so, you'll need to edit /etc/Muttrc (or better, copy it to ~/.muttrc) Find the macro definitions for and add the -r option to the less command. Phil -- 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: multiple cygwin installs
Steve M. Robbins wrote on Thursday, March 29, 2007 6:05 AM:: > Howdy, > > I had installed cygwin and used it for some months. Then I had to > install another tool (crestron SIMPL+ compiler) and discovered that > cygwin no longer worked. It turns out that the SIMPL+ compiler is > based around a cygwin gcc cross compiler. So I need to have two > simultaneous cygwin environments. > > At the moment, I'm managing with a pair of registry-mangling scripts: > one that removes the crestron entries and restores the cygwin entries, > and a second script that removes cygwin and installs crestron. It > works, but it's fairly cumbersome. > > I've searched the archives and found a couple of previous threads, > such as http://sourceware.org/ml/cygwin/2001-10/msg00625.html, but not > much enlightenment. > > I gather that the two impediments to separate installs are: the shared > registry entries, and a shared memory location. I read that you can > get around these with a recompile > (http://www.cygwin.com/ml/cygwin/2001-10/msg00651.html). But I can't > find any details on how to build a cygwin that does not interfere with > the official cygwin. Is there a configure-time option? Or do you > edit the file winsup/cygwin/include/cygwin/version.h to change > CYGWIN_INFO_CYGNUS_REGISTRY_NAME? What about the shared memory > region? > > Thanks for any insight, > -Steve Can you not just eliminate the Crestron-installed cygwin? If SIMPL+ cannot work with your current cygwin, it's broken and you need to take it up with Crestron. Any 3PP that forces one to use their (inevitably out of date) version of cygwin (and thereby killing the official installation) is IMO broken and the issue should be taken up with them. At the very least, it shows they have such little faith in their own software's robustness that they won't risk it running on an newer version of cygwin. Imagine the chaos if ALL software was installed like this. You might end up with 100 different versions of cygwin on your PC, and ProductA would never be able to talk to ProductB because they'd need two different sets of registry settings simultaneously. I'm sure their justification is that they are reducing support costs by ensuring it's running on a known platform. Only if their customer support is forced to resolve the problems caused by their installation will they learn that this is a false economy. -- 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: multiple cygwin installs (gold star)
Igor Peshansky wrote on Thursday, March 29, 2007 2:27 PM:: > On Thu, 29 Mar 2007, Christopher Faylor wrote: > >> On Thu, Mar 29, 2007 at 12:34:07PM +0100, Phil Betts wrote: >>> >>> Any 3PP that forces one to use their (inevitably out of date) >>> version of cygwin (and thereby killing the official installation) >>> is IMO broken and the issue should be taken up with them. At the >>> very least, it shows they have such little faith in their own >>> software's robustness that they won't risk it running on an newer >>> version of cygwin. >>> >>> Imagine the chaos if ALL software was installed like this. You >>> might end up with 100 different versions of cygwin on your PC, and >>> ProductA would never be able to talk to ProductB because they'd >>> need two different sets of registry settings simultaneously. >>> >>> I'm sure their justification is that they are reducing support costs >>> by ensuring it's running on a known platform. Only if their >>> customer support is forced to resolve the problems caused by their >>> installation will they learn that this is a false economy. >>> >> >> Nicely put. Can I get a gold star over here? > > <http://cygwin.com/goldstars/#PB> > Igor > -- > http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] > ZZZzz /,`.-'`'-. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) > |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski > '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! > > Freedom is just another word for "nothing left to lose"... -- Janis > Joplin Wow! Thanks chaps, proudest moment of my life! Might have to join Dave if he's still *sipping* in the talk list. -- 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: slow bash command line and scripts
[EMAIL PROTECTED] wrote on Thursday, May 31, 2007 2:53 PM:: > The response time to bash command from the command line is very slow. > For example, if I type "ls", it takes about 0.5 sec to get some > output, and after the output, another 0.5 sec for the prompt. > > Likewise, my scripts are very slow (I was comparing files in two > directories). Looking at the task manager, the CPU usage was in the > single percent. > > I could not find much in past emails, except to provide strace output. > > I am attaching the strace output to running ls (strace -o ... ls), and > also the cygcheck output (cygcheck -srv). > I've only glanced at the trace, so this is not a diagnosis, just an observation. You should certainly look into cleaning up your PATH. The same directories are mentioned multiple times, this means that, as well as having to parse a longer than necessary string, the same directories will be searched multiple times. Note that /bin and /usr/bin are usually the same in cygwin, so you only need one of them, and it should usually be first so that the shell needs to do the bare minimum to find the common commands. In general, application specific directories should only come after system directories, unless the commands in them are intended to replace system commands. In this context, "system" means cygwin first, then Windows. It's _never_ smart to have "." in your PATH, because: a) you're leaving yourself wide open to attack from malicious software (e.g. if there is a file called ls.exe in the current directory that just happens to wipe your C drive, don't expect any sympathy). b) the actual command file that runs should never depend on where your current directory happens to be (unless you explicitly type "./commandname" of course), otherwise scripts that were previously reliable will mysteriously stop working when you're in a particular directory. Phil -- 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: scripting and cygwin
John wrote on Friday, June 01, 2007 3:05 AM:: > I finished the script I have been working on. Unfortunately, > this Pee Cee version won't even finish the full data run > as it crashes with Zone Alarm. Since I have a long term good > relationship with Zone Alarm, I have to write off cygwin. > > And here are the timings I get from my Windoze cygwin machine > vs. my MacBook Os X are (comparable machines): > > Timings on Windoze cygwin: > [snip] > Zone Alarm crashes ALWAYS, won't even finish > > Timings on Mac OS X: > [snip] > > I am afraid I just have to move all this to my MacBook > and forget about Windoze/cygwin. You're comparing chalk & cheese and complaining that your mouth's full of grit. It's not the chalk's fault. It never claimed to tasted good in a sandwich. Run your script on a Mac emulator running under Windows, (without removing ZoneAlarm), then report back. Alternatively, run your script under Linux on your PC. You also haven't grasped simple logic, so I dread to think what your script is like. (Give us a laugh and post it, I dare you) Many people have experienced this: PC+Windows+ZoneAlarm+Cygwin+Script = Will not run PC+Windows+ZoneAlarm+ProgramX = Will not run PC+Windows+Cygwin+Script = Runs PC+Windows+ProgramX= Runs What sort of warped logic blames cygwin in this situation? The experience of many others is that ZoneAlarm is a badly written program that interferes with the correct operation of all sorts of software, not just cygwin. What sort of arrogant fool thinks the experience of countless others in the same circumstance doesn't apply to them? Cygwin works. I use it all day, every day and have done for years. I didn't have to do anything special to get it to work. If you can't make it work for you, I suggest that, ultimately, the problem is between your own ears, and you would be better off working on a solution to that rather than wasting our time with your mindless trolling. -- 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: [ANNOUNCEMENT] New package: brltty 3.8
Christopher Faylor wrote on Wednesday, June 06, 2007 8:26 PM:: > On Wed, Jun 06, 2007 at 02:22:30PM -0500, DePriest, Jason R. wrote: >> On 6/6/07, Dave wrote: >>> Brian Dessent wrote: Samuel Thibault wrote: > Mmm, because for a blind person this is a very basic package? Perhaps, but that doesn't mean that most Cygwin users are blind. >>> >>> Last I heard, setup.exe was not particularly friendly wrt screen >>> readers (cf. package selection). Hence the visually impaired would >>> have difficulty selecting brltty for installation. >>> >>> In addition to installation brltty also needs an amount of >>> configuration to select the type of terminal to use, and for the >>> daemon to be started. >>> >>> Despite the latter I would suggest that (at least the non-X bit of) >>> brltty should be kept in Base to make things simpler for those who >>> need it. At least until we get that revamped setup.exe :) >> >> It seems that when you trace the requirements of brltty down, you end >> up with xorg, perl, and python packages getting installed. >> >> So, do we want those to be considered part of Base? > > No. I've removed it from Base. > > cgf I agree that it shouldn't be in base, because that should be reserved for packages that are considered essential for the correct running of cygwin. Might I suggest a compromise? Create a new "Accessibility" group in setup. It would (at least for now) be the first group and just clicking the "Default" label once would switch it to "Install". It's not perfect for the visually impaired, but providing the instructions are available in a screen-reader-friendly format, it should be acceptable for all but those with the most severely impaired vision. Phil -- 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: Re: Possible bug: d does not seem to read ~/.d.conf
Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM:: > Phil, please, you don't know what you're talking about and you don't > know what I and Ronald were talking about. I'm so sorry, but my telepathy module has a malfunction. Until it's fixed, I can only respond to what is actually written. If you re-read what was posted, you'll find I was totally correct and addressed the points raised: The post talked about ~/.d.conf not being read, and "demonstrated" this by using an incorrectly entered option. If you enter the option correctly, the file "~/.d.conf" clearly is NOT ignored. The follow-up talked about the syntax differing from the info file, and since the third post claimed the information was not at variance I showed exactly which parts of the files referred to DO differ. However, there is absolutely NOTHING in the posts that preceded my response to imply that this was anything to do with $HOME differing from the user's home directory. I've no problem with WJM, but WJPBR* is not acceptable. Phil * PBR = plain bloody rude -- 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: Possible bug: d does not seem to read ~/.d.conf
Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM:: > * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500) >> Ronald Fischer wrote: >>> From >>> >>>info d >>> >>> we can see that /usr/bin/d is supposed to honour a configuration >>> file ~/.d.conf and that in this file, the boolean variable >>> hidden-files-shown corresponds to the --hidden-files flag in the d >>> command line. >> >> Hmmm, that page of the info appears to be outdated. See the Command >> Line Options section as well as /usr/share/doc/d-1.2.0/d.conf.example >> for current syntax. > > These resources don't contradict the info file but state the same. > Fact is that d under Cygwin ignores ~/.d.conf while under Linux it > works as expected. > > Thorsten You're not reading carefully enough. From the info page: | `hidden-files-shown' | Boolean option, the same as the command line option | `--hidden-files-shown'. *Note Command Line Options::. From /usr/share/doc/d-1.2.0/d.conf.example: | # 'hidden-files' - boolean option. Controls whether files with a leading | # period in their name are shown in the output. This defaults to 'false' in 'd'. | # Set to 'true' or 't' or '1' to turn on. | | #hidden-files = False Spot the difference? If you put "hidden-files = true" in ~/.d.conf it works as advertised. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Is there someone offering cygwin paid support?
Marko Loparic wrote on Friday, September 14, 2007 3:42 PM:: > Hello, > > Is there someone that could offer paid support for a cygwin problem I > have? > > I have tried to contact Red Hat but they did not seem interested in > offering support for the type of problem I have (or perhaps I didn't > reach the right person...). > > It is described in the cygwin list: > > http://cygwin.com/ml/cygwin/2007-02/msg00023.html > http://cygwin.com/ml/cygwin/2007-08/msg00468.html > http://cygwin.com/ml/cygwin/2007-08/msg00517.html > > Some people helped, but it was not enough to solve the problem. > > Thanks a lot, > Marko Nobody seems to have noticed that the group is listed as "mkgroup-l-d". This suggests that you need to set up /etc/groups properly by running the command: mkgroup -l > /etc/group or more likely in this case (as it's a network share): mkgroup -d > /etc/group For more information, "man mkgroup" and/or "man mkpasswd". No charge, no guarantee. (If it sorts out your problem, my insincere apologies go to anyone who fancied making a quick buck!) Phil -- 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 use the X clipboard
Robert Kiesling wrote on Tuesday, September 18, 2007 3:02 AM:: > I need to set the X server option, "emulate3Buttons," in order to use > the X clipboard with the Cygwin system's mouse. The FAQ tells me that > I can add, "-emulate3buttons ," to the X server arguments. > However, if I start the server with > > startx -- -emulate3buttons 10 > > all of the X server's default arguments seem to get overriden. I > would like to know where are the X server resources are located so I > can add this option without overriding the X server's default > arguments. > You can create a script file .xserverrc in your home directory that is called to actually start the server. This could be something as simple as: #!/bin/bash exec /usr/X11R6/bin/X $@ -emulate3buttons 10 Here, if you run startx without any arguments, $@ will contain the display number (e.g. ":0"), but not the default server arguments, so you would need to add them to the above line yourself. For more information, man xinit. Alternatively, start XWin using startxwin.bat and edit that to add your own options. It's a much simpler script than startx, so you're less likely to go astray. > On a related note, the server and display addresses default to > 127.0.0.1, and that limits clipboard use to clients on the local > host. Not true. The display IS on the PC where you started it, therefore it is on the localhost for clients started on the localhost. The clipboard is available to all clients running on the server, wherever they may be. > Because > this network gets its addresses through DHCP, I would like to know if > there's a way to tell the X server beforehand what the network > address is. I assume I can parse the output of Windows netstat after > booting and add the address to /etc/hosts before starting the X > server, but I would welcome any clues, hints, or suggestions how to > go about telling the resolver library about the network address with > a documented interface. There's no need for any of this. Suppose the PC where you run the server is hosta and the remote box is hostb. You start the server on hosta, where it is known as localhost:0. You then log into hostb. From there, the server would be known as hosta:0, so you would set DISPLAY=hosta:0. If hosta is not set up in your nameserver, then you would need to use hosta's IP address, however it's still not necessary, nor is it advisable. If you connect directly to the server as a named host (or IP address), you either need to use XDMCP or the insecure xhost to allow access to your server from hostb. The much preferred way is to use ssh with trusted X11 forwarding instead. To do this, you log into hostb using: ssh -Y [EMAIL PROTECTED] You need to ensure that $DISPLAY is set BEFORE you run ssh. You can ensure this by running ssh like this: DISPLAY=localhost:0 ssh -Y [EMAIL PROTECTED] However, if you start it from a cygwin shell, $DISPLAY should already be set correctly. On hostb, you will find that ssh has set up the DISPLAY to _look_ like it is connecting to a server on hostb - i.e. it will be localhost:10.0 or similar. Do not change this "because it looks wrong". It simply means that ssh has opened a port on hostb (in this case 6010), to which hostb's clients connect. Traffic on this port is forwarded over the secure link to hosta's port 6000. For more information (including what you may need to set up to enable X11 forwarding), consult the FAQ: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#remote Finally, this is the wrong list for X related questions. Check out http://cygwin.com/lists.html I've redirected replies to the correct list. Phil -- 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: When I start a process in bash - which pid is correct - Windows Task Manager or ps -ef
Brian Keener wrote on Wednesday, October 10, 2007 11:31 PM:: > I have an application that I have been trying to gather info on and it > hangs but it seems finding the pid is difficult for attempting to > attach to it. > Use ps -el instead of -ef. That lists the winpids too. Phil -- 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/
Workaround for silent linkage errors
We seem to be getting a lot of messages along the lines of "I ran xyz and it did nothing." The typical response is something like "if you echo $? it is probably 53 which indicates a missing DLL." This usually gives rise to a further email asking where to get the missing DLL. Attached is a short script which should provide a workaround for the problem and hopefully reduce the mailing list traffic. It is designed to be installed in /etc/profile.d and uses one of two methods: 1) Use $PROMPT_COMMAND We can use the PROMPT_COMMAND envvar to do the checking for us. Although I use it myself, I imagine $PROMPT_COMMAND is a little- used bash feature, so very few users would override this in their own rc file, and will therefore get to see the message. I have made the variable read-only so that should a user want to override it, they'd have to take extra steps and in doing so would learn why it is set up that way. The definition of $PROMPT_COMMAND includes a comment, so that users echoing $PROMPT_COMMAND will be instructed to refer to /etc/profile.d/dllcheck.sh. It's by no means a perfect solution, because the error is only detected if the last command executed before the prompt failed. Most of the reported problems were related to running a single command, and not a command within a script, so this method should be fine for the majority of cases. 2) Trap the error This might be considered a better solution, as it also works inside functions (if set -E is used) and sourced scripts, but it has the disadvantage of printing the message twice if it was the last command in the script which failed - once as the error is trapped within the script, and once as the return status of the script is detected. Another potential problem with the second method is that scripts often trap errors themselves, and if such a script were sourced, it would leave the trap handler changed on exit, so this mechanism is more prone to being defeated. The file contains instructions on how to switch to the second method. I've lifted the copyright message from Eric Blake's 00bash.sh script, but essentially you're free to do whatever you like with it. I've only tested it under bash, so one modification you may wish to make is to ensure that it works (or at least does not cause other errors) when using shells other than bash. Phil dllcheck.sh Description: dllcheck.sh -- 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: Workaround for silent linkage errors
Eric Blake wrote on Wednesday, November 14, 2007 1:56 PM::
> According to Phil Betts on 11/9/2007 10:15 AM:
If anyone missed this because of ultra paranoid virus filtering (it
had a .sh attachment), it's here:
http://cygwin.com/ml/cygwin/2007-11/msg00173.html
I didn't get a copy myself, but saw it was in the archives so didn't
re-post.
>> It is designed to be installed in /etc/profile.d and uses one of
>> two methods:
>>
>> 1) Use $PROMPT_COMMAND
>
> Won't work as posted, since profile.d is loaded by all bourne-style
> shells, but 'declare -r' is bash-specific.
I realise that. I just wanted to get the idea out there to gauge the
reaction before spending too long on a bullet-proof solution.
> Why not propose a patch
> for /etc/profile in the base-files package instead, to change the
> default cygwin prompt for new installations? And even if you want to
> keep this as a profile.d script, at least do some sanity checking
> that you are only installing it for bash.
Will do. You seem to imply that /etc/profile is only installed for
new installations. Is that correct? Given that a fair number of the
emails about this issue are from people who claim to have upgraded,
I'd prefer provide a solution that everyone will pick up.
Are there any other bourne-style shells apart from the following that
I should test with?
* ash
* bash
* pdksh
* bash-invoked-as-sh
I see you use /proc to detect the current shell. Is that the most
reliable way (for my purposes)? Whereas you are detecting if the
currently running shell is the file you are about to overwrite, my
purpose is to determine the shell's features. Would it be preferable
to test for some signature feature of each flavour rather than relying
on the name of the executable? If so, which tests would you recommend?
>> I have made
>> the variable read-only so that should a user want to override it,
>> they'd have to take extra steps and in doing so would learn why it
>> is set up that way.
>
> Yuck - since the variable is made read-only in a profile.d script, the
> only way to undo that is to edit the profile.d script. Ouch. At
> least allow for an environment variable override, rather than
> requiring editing a system file.
Fair point. I wrote it after receiving yet another email about exactly
the same issue as hundreds of others, so I was feeling a tad militant!
I've since been to my happy place so I'll incorporate the idea.
>> It's by no means a perfect solution, because the error is only
>> detected if the last command executed before the prompt failed.
>
> Have you looked into making your PROMPT_COMMAND use PIPESTATUS? For
> that matter, I avoid PROMPT_COMMAND, and get all my exit statuses at
> once with this PS1:
>
> PS1='[EMAIL PROTECTED] \[\033[35m\]'\
> '(${PIPESTATUS[*]}) \[\033[33m\]\w\[\033[0m\]\n\$ '
Learning something new every day - the advent of PIPESTATUS had slipped
under my radar. I'll investigate. I don't think you were suggesting I
should use PS1, but in case you were, I specifically wanted to avoid
using it as so many people change that. It might be worth using for the
other shell flavours though.
>> This might be considered a better solution, as it also works inside
>> functions (if set -E is used) and sourced scripts, but it has the
>> disadvantage of printing the message twice if it was the last command
>> in the script which failed - once as the error is trapped within the
>> script, and once as the return status of the script is detected.
>
> Ah, but you could have your trap change the return status to some
> other failure value, so that the message doesn't print a second time.
Another good point. I'll incorporate that too.
It'll probably be over a week before I get chance to do anything more
with this. If anyone has any other comments, now would be a good time
to raise them. I'd be particularly interested in similar solutions
for the other shell flavours.
Phil
--
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: cygwin install possibly stuck
adamb wrote on Monday, November 19, 2007 5:12 AM:: > only found 1: Maybe that's all *you* could find, but cygcheck almost certainly would have found another. If you had followed the instructions given in the first response you received from Eric, you'd almost certainly have been up and running by now. Instead of following the instructions here: > Problem reports: http://cygwin.com/problems.html You decided to ignore them completely and uninstall instead. Let's get this clear, you requested help, then ignored the instructions you were given, then compounded the offence by effectively saying "I've ignored you and did my own thing, and now that's not worked either". Yet, you still expect people to rush to your assistance? Instead of what should have taken just 2 messages: Q) I've got a problem, here's the output of cygcheck... A) This is your problem, do x, then y, then z to fix it we have already got to 8 messages (9 including this) and you STILL haven't posted the cygcheck output and are therefore no closer to a resolution. > Sent from the Cygwin list mailing list archive at Nabble.com. Why am I not surprised? -- 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: socket : MSG_WAITALL isn't defined
Corinna Vinschen wrote on Wednesday, November 28, 2007 2:57 PM:: > On Nov 28 15:24, patrick ficheux wrote: >> Hi, >> >> I want to use recv() with MSG_WAITALL [...] > > Don't you read earlier replies on the list? > > > Corinna It seems he's running an old version of Brain which had a problem with recv()! -- 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: need help with bash -c with cygpath
Jay wrote on Friday, January 11, 2008 3:14 PM:: >> That's still somewhat wasteful, starting bash just to get a vim >> alias - why not use the full name gvim, and bypass the bash process >> to begin with? > > you right, i'm going to remove it, thanks. > > My main problem now is that for some reason the leading backslash on > UNC names is getting dropped when calling bash -c from the windows > command prompt, even when using just single quotes. So if you run > this from a windows command prompt: > > H:\>C:\cygwin\bin\bash -v -c '\\UNC_PATH\Dir' > \UNC_PATH\Dir <--Leading backslash dropped > /usr/bin/bash: UNC_PATHDir: command not found > > It drops off the leading backslash. > > When you run it from Cygwin bash: >> bash -v -c '\\UNC_PATH\Dir' > \\UNC_PATH\Dir <--The leading backslash is preserved. > bash: \UNC_PATHDir: command not found > > I know i can make it work by piping the path into sed, but I'm just > wondering why i'm losing the leading backslash when running from > windows. > > Maybe dos is passing in the single quotes as double quotes. > "dos" (i.e. cmd.exe) does not have the same quoting rules as bash, so \\ inside single quotes means the same as it does inside double quotes in bash. Why are you even trying to use backslashes? There's no need (even in cmd.exe), but there's certainly no point in using them in a posix command. Just replace all backslashes with forward slashes and you've sidestepped the problem. If you absolutely MUST have backslashes, from cmd.exe, you need to double each backslash: H:\>C:\cygwin\bin\bash -v -c 'UNC_PATH\\Dir' (actually only the first really needs to be doubled, because \ has no special meaning if it's followed by a letter) Phil -- 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: Warning msg: multiple cygwin1.dlls
Fergus wrote on Monday, February 04, 2008 6:28 AM:: > Sorry to return to this old favourite. For ages (years) I have had > both /usr/bin/ and /bin/ set in my PATH and cygcheck -srv reported > both as d:\bin. I just removed the latter from the PATH and now get > exactly one report of d:\bin. > BUT cygcheck -srv still claims > Warning: There are multiple cygwin1.dlls on your PATH. > As far as I can tell and I have been SCRUPULOUS there is exactly one, > not many, and it's in the obvious place d:\bin. I'm not getting any > problems with functionality. Nor do I want to trouble you with output. cygcheck tells you where each of the DLLs are. Since you don't want to trouble us with output, you could at least read it yourself ;-) -- 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: undefined reference to `_msgDebug' in GCC
Anik Pal wrote on Saturday, February 02, 2008 9:05 AM:: > I am trying to using a library in my code whose default compiler is > MSVCRT. When I try to compile that code in cygwin GCC environment I > get the following errors > > F:/geolog6.6.1/lib/libgeolog6.a(fileprintf.o):C:/development/ptc:(.text+ 0x9) >> undefined reference to `__chkstk' [snip] >> more undefined references to `_msgDebug' follow > > Can anyone tell me which cygwin-mingw library to be added to get rid > of this linking error? > > My make file linking option I'm providing as follows > > -LF:/geolog6.6.1/lib -lcgg -lgeolog6 -llicence -llogs_dll -lPGILc_dll > -lPGILcTool_dll -lcgs -llmgr9a -LD:/cygwin/lib -lcygwin > -LD:/cygwin/lib/mingw -lmsvcrt -Bstatic -LD:/cygwin/lib -lm > First, don't use windows pathnames. Cygwin is a POSIX environment, so use POSIX pathnames (I.e. "/cygdrive/f/" instead of "F:/") Second, you're linking with cygwin AND msvcrt and potentially also mixing cygwin and mingw libraries. Don't do that. The cygwin, msvcrt and mingw are fundamentally incompatible. [Although it is possible under very specific circumstances to mix cygwin and msvcrt, it requires knowledge of the internals of both libraries, and if you had that knowledge, you wouldn't have posted your question, so the advice stands] Make your mind up whether you want to write a POSIX program or a Windows program and stick to your decision. Third, let the compiler choose the C runtime library. You don't specify -lcygwin, nor the path to the standard library locations, so the only -L you need is "-L/cygdrive/f/geolog6.6.1/lib" Fourth, libm is integral to cygwin1.dll, so you don't need -lm. The math library supplied with cygwin is only a stub to support makefiles such as yours that assume it's necessary. Phil -- 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: undefined reference to `_msgDebug' in GCC
Anik Pal wrote on Tuesday, February 05, 2008 3:12 PM:: > Phil, > Thanks for the info you provided. I'm not conversant with GCC. > I remove the path for regular library like libm.a, and all the paths > specified in posix , now my linker option is as follows > > -L/cygdrive/f/geolog6.6.1/lib -lcgg -llicence -llogs_dll -lPGILc_dll > -lPGILcTool_dll -lcgs -lgeolog6 -L/cygdrive/D/cygwin/lib/mingw > -lmsvcrt > -Bstatic -lm You've only done half of what I said. You only need this: -L/cygdrive/f/geolog6.6.1/lib -lcgg -llicence -llogs_dll \ -lPGILc_dll -lPGILcTool_dll -lcgs -lgeolog6 Here's why: -L/cygdrive/D/cygwin/lib/mingw = look in the mingw lib directory when linking. You don't want to do that if you're compiling a cygwin program, because the mingw libraries expect the program to be linked with msvcrt (see below) -lmsvcrt = link to the Microsoft Visual C Runtime library. You definitely don't want this if you're compiling a cygwin program. -Bstatic -lm = link with the static math library. As I previously explained, the math library is integral to the cygwin C runtime library, so you just don't need this. You should never specify a C runtime library to the compiler because the compiler is generating code for a specific runtime library and if you force the linker to link with a different one you are likely to get all sorts of linkage errors. If the above options don't work, then it's likely that your code (or one of the libraries in geolog6.6.1/lib has calls to native Windows functions. If this is the case, you have two options: 1) replace all Windows function calls with their POSIX equivalent. This will make your code portable to many more platforms. 2) If this is not possible, compile a native Windows program. For this you can either use the mingw version of gcc (where you'll need to use DOS style paths), or you can use cygwin's gcc in cross-compilation mode by specifying the -mno-cygwin option to gcc. Note that if you do this, you won't be able to link to any of the cygwin libraries. You don't need to change the link options from those given above - gcc will automatically link with the msvcrt.dll If you do decide to compile a native windows application, any further questions would be off-topic for this list - the clue is in the "no-cygwin" bit ;-) > But I'm not sure how to remove the dependency on libmsvcrt.a (that > comes with mingw lib in cygwin). If you've followed the above, you should now be able to answer that yourself. > What is the equivalent lib in cygwin/lib? cygwin1.dll is cygwin's libc. Just leave it up to the compiler to figure out which C library it needs to link to. > Moreover I followed the solution stated in the following > url to get rid of linking "undefined reference symbol __chkstk" > http://eegeerg.blogspot.com/2008_01_01_archive.html#4158852069709002699 > which actually states to copy chkstk.OBJ from MSVC/lib and rename to > chkstk.o and link with this. > Now linking error goes but when try to execute this exe, it doesn't > gives any error message but terminate unexpectedly. That link says this: | This is the error you get when you try to link a msvc6 compiled ^ | library with gcc on mingw If you try to mix MSVC code with cygwin code, you are asking for trouble. As I said in my original reply, decide whether you want a cygwin program or a native Windows program and stick to your decision. Phil -- 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: Incomplete environ when running MinGW apps?
Paul Leder wrote on Thursday, February 07, 2008 3:31 PM:: > Eric Blake wrote: > >> Bash has two variable namespaces - shell variables, and environment >> variables. Are you sure SHELL was exported to the environment, and >> not just in the bash shell variable namespace? > > thanks - I had no idea there were 2 variable namespaces. It looks like > everything I can see in 'environ' was explcitly exported in > /etc/profile, or ~/.bashrc, or picked up from Windows. > > Is there a way for C programs to pick up the contents of the shell > variable namespace? In particular, is there some way I can pick up > SHELL, or some other way that I can find out if my app's running on > bash? > > Thanks > > -Paul Just export the variables you want. That's the whole point of the export command. -- 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: Uninstalling Cygwin
PEDRO MACANAS VALVERDE wrote on Tuesday, February 12, 2008 9:45 AM:: > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre ^^^ ^^^ > de Larry Hall (Cygwin) > Enviado el: lunes, 11 de febrero de 2008 16:38 > Para: [EMAIL PROTECTED] ^ How many times do you have to be told? DO NOT PUT EMAIL ADDRESSES IN YOUR REPLIES I've told you on the X list, and I'm pretty sure CGF and Larry have told you on this list, and maybe others too. JUST STOP IT! There has been quite a bit of spam getting through from these lists recently and it's almost entirely because of people like you who just can't be bothered to do the right thing. Phil -- 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: sshd.log /var/empty must be owned by root and not group or world-writable.
Corinna Vinschen wrote on Monday, February 18, 2008 12:12 PM::
> + echo "${LOCALSTATEDIR}/empty is existant but not a directory."
Perhaps:
+ echo "${LOCALSTATEDIR}/empty exists but is not a directory."
would avoid a typo (it's "existEnt"), and sound less like a Google
translation ;-)
Phil
--
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 programming: testing for empty string
bootleg86 wrote on Wednesday, March 05, 2008 9:28 AM::
> Hi,
>
> I'm trying to find the time of a file by doing this.
>
> filetime=`ls -l --time-style=+%a:%H:%M /tmp/1.txt | awk '{print $6}'`
>
> if [ -z "$filetime"]; then
> echo "File does not exist"
> else
> echo "Time file: $filetime"
> fi
>
> However, when the file does not exist and filetime returns an empty
> string, it does not evaluate [ -z "$filetime" ] to true
> I have also tried the reverse which is
>
> if [ -n "$filetime"]; then
> echo "Time file: $filetime"
> else
> echo "File does not exist"
> fi
>
> but I still get the same results.
>
> What does $filetime evaluate to when the command exits with an error?
WJFFM
However it's not good style to trigger a foreseeable error and rely
on the error handling of a command to do what you want. Apart from
anything else, doing it your way will be slower due to the number of
unnecessary processes invoked when the file doesn't exist.
Instead, first test if the file exists, and only if so print its time:
if [ -e /tmp/1.txt ];then
filetime=`ls -l --time-style=+%a:%H:%M /tmp/1.txt | awk '{print $6}'`
echo "Time file: $filetime"
else
echo "File does not exist"
fi
Also, if you don't actually need $filetime after you've printed it,
save yourself a bit more time by:
echo -n "Time file: "
ls -l --time-style=+%a:%H:%M /tmp/1.txt | awk '{print $6}'
--
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: Easy question
Troy Bull wrote on Wednesday, March 12, 2008 5:45 PM:: > Greetings > > I use rxvt and I use the -fg and -bg to set colors. Where can i find > a list of the colors that I can put in there. I know I can do the > obvious ones, Black, White, Blue, etc but I also found "Wheat" and > some other ones work. I would like to know if there is a list in a > file anywhere that says all the ones that work. > > > > Thanks > Troy If you've installed the xorg-x11-libs-data package, you'll find the list in /usr/X11R6/lib/X11/rgb.txt If you haven't installed that package, and don't want to, I'm sure a google for rgb.txt will uncover a copy or two. Another option if you've installed the xorg-x11-bin package is to run the showrgb command. Unless you can't resist the idea of requesting a foreground such as PapayaWhip, you can also specify colours numerically using the standard X11 syntax, e.g. "rgb:c0/00/f0", or "#c000f0". "man X", then search for "COLOR NAMES", for more extensive info. Phil -- 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: mmap call gives invalid argument
Corinna Vinschen wrote on Wednesday, November 19, 2008 3:45 PM:: > On Nov 19 22:56, Carlo Florendo wrote: >> On Wed, Nov 19, 2008 at 7:28 PM, Corinna Vinschen wrote: >>> On Nov 19 14:49, Carlo Florendo wrote: Trees removed to enable wood to be seen... Table at 0x3BEE3000. > 152 61108 [main] dmidecode 540 mmap64: addr 0, len 13783, prot 1, >flags 1, fd 3, off 1005453312 ^^ >Where does dmidecode get this offset from? The address is >beyond the memory size available. off = 1005453312 = 0x3BEE len = 13783 = 0x35D7 Based only on the code snippet provided, the offset is the table address (0x3BEE3000) rounded down to the nearest page boundary (0x3BEE), and len is the table length (0x5D7) plus the offset of the table into the page (0x3000) I've not looked at the cygwin mmap code or the /dev/mem code, but assuming it's close to the linux implementation I'll proceed... From a linux man page describing the errnos returned: | EINVAL We don't like start or length or offset. (E.g., | they are too large, or not aligned on a PAGESIZE | boundary.) This man page is pretty vague on whether the length should be a multiple of getpagesize(), but a Tru64 man page is more explicit: | len Specifies the length in bytes of the new region (rounded up | to a page boundary). So: Firstly, is the table address correct? Since lseek also fails, it would suggest not. Secondly, the length (i.e. mmoffset+len) should be rounded up to a multiple of the page size. Perhaps the cygwin implementation is stricter in this regard than linux. HTH Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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 wants to revert my upgrade of Emacs
Jonathan Ferro wrote on Friday, November 21, 2008 7:05 AM:: > Casual browsing recently revealed that one of my all-time favorite > software packages, Emacs Calc, has returned to active maintenance and > is part of the GNU Emacs distribution. My thought: why does my > Cygwin installation not have it? > > Setup run 1: Fiddling with Setup shows that I can turn all three of > emacs, emacs-el, and emacs-X11 to "22.1-3" instead of "21.2-13". > Score! > Problem: 21.2-13 is uninstalled and nothing is installed. It's too late now, but you can usually find out why by checking the setup log files. > Setup run 2: I can turn all three packages to "22.1-3" and *manually > check* the binary box, something I've never had to do manually > before. > This correctly installs all 3 packages, for now. > > Setup run 3: When rerunning Setup to look at something else, > fortunately I am in the habit of always looking at the "Partial" view > before hitting Next, and I see that it has queued up all three > packages to be reinstalled to version "21.2-13". > I have canceled out of that Setup session, but I'd like to figure out > how to get my choice to "stick". > > Am I asking in the right place, regarding the dependency information > for the emacs package? > Should this be regarded as a general problem? (I.e., is there some > technical or policy issue preventing 22.1-3 from being listed as the > "new" version?) > Is there something I can do to remove these packages from the > maintenance upgrade list in my installation for now, so that I can > stick with my chosen version? > The problem is that the current emacs is 21.2 (see the setup.ini in your package download directory). The 22.1 version is experimental ([test]). Setup defaults to "upgrading" to the current stable version, which unfortunately means it tries to downgrade any experimental packages. This is one of the costs of living on the bleeding edge (yes, I know 22 has been out a while now) Although your choice won't stick, you can click on the emacs version number in setup until it shows "Keep" to prevent it downgrading. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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 -mno-cygwin causes different program behavior
Eric Blake wrote on Thursday, December 04, 2008 1:42 AM::
> According to C-Programmer on 12/3/2008 6:29 PM:
>> But if I compile using the following command line argument:
>> $ gcc -mno-cygwin -o ioProg1 ioProg1.c
>
> Then you are no longer using cygwin, and this is almost more of a
> question for the mingw list.
>
>> I find that the DLL being used is msvcrt.dll and the program behaves
>> as if the gets( name ); line had come before the printf("What is
>> your name?"); line. Very strange!
>>
>> Any ideas on why this is happening?
>
> Yes. It's called buffering. Native Windows apps have no idea that
> cygwin emulates pty's with pipes, and blindly assume that all pipes
> are non-interactive. For performance reasons, when talking to a
> non-interactive client, all stdio libraries perform block buffering
> instead of line buffering when stdout is determined to be
> non-interactive. So, because you are running a native windows app in
> a cygwin console, your app doesn't realize that you wanted line
> buffering, and so you don't see output until 4k or end of process,
> even though the printf completed before the gets.
You beat me to it. I would only add that it is a mistake to rely on
the default buffering mode of stdio, particularly for interactive
programs. If you require a specific mode, you should always set it
using one of the functions setbuf, setbuffer, setlinebuf, or setvbuf.
In this case, you should call setlinebuf(stdout) to ensure that the
newline flushes the output.
If instead, you wanted the input to appear on the same line as the
prompt, you would need to call setbuf(stdout, 0) to force unbuffered
output.
Alternatively, you can just call fflush(stdout) before calling gets().
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
--
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: Finally managed to create a jailed SFTP server, but how secure?
TheO wrote on Thursday, December 04, 2008 4:48 PM:: >>> I understand why all these virtual directories are necessary at the >>> absolute '/' root level. But here I refer to /cygdrive which is >>> created inside the jail directory, which means in absolute path, >>> /jail/cygdrive (/jail being the root >> of my jail). Inside the jail, only /cygdrive is created, no other >> virtual directories (/proc or /dev/xxx) or files are created. >> >> Created or not, they exist. Try it. >> > > I tried it from jailed SFTP session: > > sftp> cd /dev > Couldn't canonicalise: No such file or directory > sftp> cd /proc > Couldn't canonicalise: No such file or directory > > They don't exist. You also need to try symlinks that point outside the "jail". Try creating them both from the shell and within SFTP. You should also check that non-interactive SFTP observes the jail (that is specifying the file to transfer on the command line). Frankly, there are loads of things that you would need to test and you can never be sure you've checked all possible mechanisms. Given that the chroot jail is really an open prison under Windows, one has to wonder if it's worth the effort, and what you have proved if all of your tests have passed. The best you can say is that you are protected against inadvertent access and (possibly) someone casually poking around. Don't forget that even if you decide SFTP is "secure enough", you need to consider the system as a whole. One of the problems with Windows' security in general is the number of open ports and services that are running. If unauthorized users are able to gain access to the system via any other route, then any security SFTP gives you is totally illusory. You would really need an external, aggressive firewall to be sure that the only possible external access was via SFTP. You can't rely on just disabling services, because I have known them to become enabled again after installing updates (thanks MS!) Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Problems with remote programs using ncurses (aptitude)
Brian Dessent wrote on Monday, December 08, 2008 2:31 PM:: > SO wrote: > >> I have problems opening remote programs using ncurses library. >> Aptitude for example. Menus and other interface components are just >> garbage on my term on windows vista. Is there a solution for that? > > The answer will depend on what terminal you're using. But first a > summary of the problem: The application wants to draw nice looking > boxes or lines. So it checks the value of the TERM environment > variable and then asks its local terminfo database what the > appropriate characters are for that terminal, and prints them. > Simple, so far. > [ lots of good stuff snipped ] > > Brian Wow! May I suggest a gold star for Brian for this and other recent responses which have shown patience and insight in the face of sparse information and have gone well beyond the accepted degree of helpfulness (for OSS or commercial software), without ever lapsing into cynicism or adopting a patronizing tone. I suspect the ever helpful Brian may have stepped up a gear to compensate for the (hopefully short) absence of Dave, who in fairness, also deserves a lifetime achievement gold star. Alternatively, you might want to ostracise him for breaking with the traditional cygwin WJM ethic and setting a bad precedent :) Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: cygwin and cygwin-xfree lists to merge
Christopher Faylor wrote on Wednesday, December 10, 2008 5:49 PM:: > The historical reasons for merging the cygwin and cygwin-xfree lists > no longer seems to exist so I am contemplating merging the two lists. > > If anyone has a compelling reason why this should not happen please > send it to one of the two lists. If I don't hear a coherent argument > against doing this, I'll throw the switch over the weekend. > > Btw, I'm only mildly sympathetic to arguments like "It will be more > email for me". I'm more concerned with having to constantly shuttle > people back and forth between the two lists. Unless there is a > compelling argument to the contrary, I think that the fact that people > are confused about which list to use outweighs the increase in email > traffic for people who just want to hear about cygwin/x. > > cgf Although I currently have rules to put the two lists in different mail folders and it works well for me, but I'd also be perfectly happy with the change. There are plenty of borderline issues where it's not clear (to the user at least) whether the problem is X related or cygwin related, so a unified list removes any need to speculate. With the 1.7 release now officially available for public test, there are bound to be issues in X apps, where the cause is really in the cygwin DLL, so merging the lists asap will save everyone having to play the guess-the-list game. A couple of things to consider (although you're probably way ahead of me): Will mail sent to the xfree ML email address be diverted (or mirrored) to the cygwin ML? Human nature being what it is, it's unrealistic to expect everyone replying to an old thread to remember to change the To: line. Also, what will happen to the archives? Will they be merged too? If they are, any links to xfree archived posts (both within the ML itself, and also from bookmarks/blogs/forums/other MLs/etc) will be broken. Would it be possible to alias the old URLs to avoid breaking links? If the archives are not merged, the threading should at least be maintained (both ways) between the old xfree list and the merged list. (i.e. a reply to a message on cygwin-xfree which goes to the cygwin ML needs the References entry to point back to the xfree archive, and the xfree message needs the Follow-ups entry to point to the cygwin archive). Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: source for tree command?
Steve Lefevre wrote on Sunday, December 14, 2008 11:02 PM:: > Larry Hall (Cygwin) wrote: >> Steve Lefevre wrote: >>> Hello - >>> >>> I'm desperately looking for a source for the tree command in cygwin. >>> It isn't listed separately in any of the package sources that I >>> looked at. I tried googling and search the cygwin website, but they >>> just return results for "source tree" or "filesystem tree" -- >>> nothing about the tree command. >>> >>> Has in been abandoned from cygwin? >> >> I'd suggest you look for the package that the command is in, either >> through or via 'cygcheck -p tree'. Neither of >> these narrow things down very well for me to point you more directly >> so I can only say that I would recommend that you >> 'cygcheck -p $(which tree)' to see if that unearths a potential >> package for you. Once you find it, fire up 'setup.exe' and make >> sure you >> choose the 'Src?' box for the package. The result will go in >> '/usr/src'. > > Looks like my memory made something up -- Thorsten says it was never > included in cygwin. That would make it difficult to find! > > I tried looking in the package search on the website, but of course I > didn't find it. I thought it was due to ubiquity of the term 'tree', > but it looks like it's because it just wasn't there. > > Thanks for the help! > > Steve On my system: $ cygcheck -f $(which tree) tree-1.5.0-EL-1 This (the EL part) means it came from Eric Lassauge's site. See http://lassauge.free.fr/cygwin/release/ Try adding http://lassauge.free.fr/cygwin/ in setup as a custom download site in order to pick up Eric's packages. I think you'll need to run setup with the --no-verify option to use it. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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 get mmap page size?
Jay Foad wrote on Friday, January 16, 2009 12:24 PM:: > I have an application that wants to use mmap() to read a file, but > only if it can guarantee that this will leave one or more zero bytes > after the end of the contents of the file in memory: > > if ((filesize & (pagesize - 1) != 0) > use_mmap(); > else > use_read(); > FYI, this is not good practice (although I fully understand why you might want to do it). From the mmap man page on an OSF1 UNIX box at work: | If the len parameter is not a multiple of the page size returned by | the sysconf(_SC_PAGE_SIZE) call, then the result of any reference to | an address between the end of the region and the end of the page | containing the end of the region is undefined. and: | + If the end of the mapped file region is beyond the end of the | file, the result of any reference to an address in the mapped | file region corresponding to an offset beyond the end of the | file is unspecified. In other words, you're relying on system dependent behaviour if you reference memory beyond the end of the file. Your requirement "only if it can guarantee that this will leave one or more zero bytes after the end of the contents" cannot be satisfied if system independence is required (or may be in future). If you ever build your code on other systems, any bugs due to this would probably be really tough to track down, may be quite subtle, and may pose a security risk. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 'man' page for 'mintty' for review
On Thursday, February 05, 2009 7:48 PM Lee D.Rothstein wrote:
> MinTTY users,
>
> Please, if you would, review the attached 'man' page -- 'mintty.1'.
> Andy Koppe intends to fold it into the 0.3.6 MinTTY release.
>
> Comments, corrections, addtitions to this list, please.
I haven't checked all the details, but most of it seems OK to me.
There are a few points that you may want to consider.
I don't think the man page should contain installation instructions.
If you're reading the man page, mintty is already installed, so the
instructions just get in the way of the more useful information. They
should instead be put in a plain text file in the root of the source
package (and perhaps also in a README in /usr/share/doc/Cygwin).
The reference to the cygwin home directory in the description of the
--config option is potentially confusing (presumably why ('~') is
added). A novice cygwin user might think "cygwin home" referred to
/home rather than /home/user or wherever $HOME point. I think it
would be better to refer to "the user's home directory", which would
be more consistent with the other references. Also, the reference to
~ is only applicable within a cygwin shell, so anyone trying to find
~/.minttyrc using cmd.exe is liable to be confused.
I think you should change this:
| There is also a discussion forum available at this site.
which is misleading, to something like this:
| There is also a mailing list for discussing Cygwin related issues.
| See http://cygwin.com/cygwin/lists.html for details. Please read
| the advice at http://cygwin.com/problems.html before posting a
| problem report.
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
--
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: grep -P regexp problem
Andriy Sen wrote: > Below is an example of the problem. > > G:\>cat test.s > a > 1 > > G:\>cat test.s | grep -P "[^0]1" > a > 1 This is not cygwin-specific, so it is really OT for this list, that being said... grep -P treats the whole input as a single string, and outputs the line (or lines) containing the match for the pattern. [^0] matches ANYTHING except 0, including linefeeds. In your case, the [^0] is matching the linefeed preceding the 1. That linefeed is considered part of the line "a\n", so that line is included in the output. In other words, although it looks like there are two matches output, in fact there is only one match, and that is "a\n1\n" Assuming you wish to match single lines containing a character other than 0 followed by a 1, you probably want the pattern to be '[^0\n]1' It's probably a bit clearer if the test file is a bit bigger: $ echo -e 'a\n1\n2\n3\n4\n1\n2\n21\n' > test.txt $ grep -P '[^0]1' test.txt a 1 4 1 21 This output contains 3 matches "a\n1\n" "4\n1\n" and "21\n", whereas: $ grep -P '[^0\n]1' test.txt 21 only matches single lines with a 1 that follows anything but 0. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: Want to let variable pass to cygstart.
Hongyi Zhao wrote: > On Wed, 11 Mar 2009 04:37:46 +, Dave Korn > wrote: Please don't quote raw email addresses. It only feeds the spammers. > > It's bash shell metacharacters. The '&' character terminates a > command and > >puts it into the background. The simplest way is to use single quotes > ' ' > >around the URL you want to cygstart. > > Thanks a lot. Except that single quotes will also prevent variable substitution. If you want to use metacharacters AND variables, you have to use the backslash to escape the metacharacters. Alternatively, you could concatenate strings like this: 'stringA&stringB'$variable'stringC&stringD' Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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/
/etc/alternatives was RE: [Re: GCC 4 installation problem]
Dave Korn wrote: > Sounds more to me like you forgot to use the alternatives program to > configure the alternatives and have been messing around manually in its > private data directories and broken it. > > (You're not the first person to do this. For some reason it seems to > be a hard-to-resist temptation for people to just dive into the data > directories and start tampering, rather than say reading the > alternatives readme or man/info page which would explain the easy-to-use > command-line syntax by which alternatives.exe will switch over the > symlinks correctly.) I see two problems here: 1) Unless you already know that /etc/alternatives is a 'managed' directory, there's nothing to suggest that there's any tool associated with it, and certainly nothing to suggest that there's an associated database. 2) It's so easy to manually change the links that it's unlikely anyone is going to spend time looking for some (possibly non-existent) tool to do it. By the time you've found the right tool, you could have changed the link and got on with whatever you were trying to do in the first place. When the directory first appeared on Linux, I thought the links were just set up manually. It took me a while to discover that they were managed, and that was only by digging around in RPMs for post-install scripts to find out what kept changing my X desktop manager after an update. For the first problem, I think it would help avoid installation problems if the directory contained a simple README file explaining how to properly maintain the links, and why manually changing them is a bad idea. To avoid looking like just another link, and thus getting overlooked, I think this should be a real file, rather than a symlink to the README in the doc directory. Maybe Chuck could add this to the cygwin alternatives package, or perhaps he would prefer the upstream chkconfig maintainer to consider it. For the second problem, perhaps it would also help if the names of the links in the alternatives directory were a hash of the program name. E.g. /usr/bin/gs -> /etc/alternatives/9ad6a289eea9c92be09d3a5a8bc737e6 /etc/alternatives/9ad6a289eea9c92be09d3a5a8bc737e6 -> /usr/bin/gs-x11 where 9ad6a289eea9c92be09d3a5a8bc737e6 is the md5sum of "/usr/bin/gs". This would make it much more obvious that the links were managed, or at least give one pause for thought before diving in. Phil This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: 'no acceptable C compiler found in $PATH' error message on install
Jaroslav Rynik wrote: > when I wanted to install, the program with cygwin (using package for > NetBSD), the error message "no acceptable C compiler found in $PATH" > came up. This list is for X related questions only, setting the follow-up address to the main cygwin list. > However, I have installed cygwin directly from web not unsellecting any > option, so the instalation should be complete. The program is > installed in D:\pokus\cygwin directory. Only a limited set of packages is installed by default. You have to manually select the compiler(s) and other development tools. Just re-run setup.exe and select the appropriate gcc packages. > To keep track all the steps I made, I send the picture of 3 screenshot > showing all I have done until the error message appeared. I also attach > the log file made by cygwin after the action. > > If you need any further information, feel welcome to let me know. > It would have been better if you had followed the instructions in this link: > Problem reports: http://cygwin.com/problems.html In particular, note the part about *attaching* the output from running "cygcheck -svr". That would let us know which packages were actually installed. If re-running setup doesn't solve your problem, then that attachment would be very useful. Phil This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange.
RE: cygwin commands (cat,grep) not working in my windows 2008 machine
sudhap85 wrote: >I am using windows 2008 machine. I have installed latest cygwin. > Here I am facing problem with the "cat" "grep" commands. In command > line its working fine. but In my scripts it's giving error. So what's the error? Without this as a clue, we can only guess. How are you running your scripts? (e.g. from a bash shell, a cmd shell, or from a shortcut) My WAG is that $PATH in the script is different from $PATH on the command line. > Am using PERL script for my testing. These commands are not working > in the following scenario, > 1. cat file1 > file2 > 2. grep 'compileCFFilters' MHSlog >> resultfile > I have also installed the Activeperl in my system. > Also, I am running the script with PERL 5.8.0 version. Please read and follow the instructions in this link: > Problem reports: http://cygwin.com/problems.html Pay particular attention to the instruction to run "cygcheck -svr", *attaching* the output to your reply (i.e. don't paste it in). Phil This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: don't know why ./configure command fails
Jaroslav Rynik wrote: > Hello, > > when I wanted to install a program under Cygwin (NetBSD package of > instalation program), the error message saying that no suitable C > compiler was found appeared. > > However, during the instalation I reset all the components from > "Default" to "Install". I also tried to run setup.exe once again, but > nothing changes. install.exe in "bin" directory finishes as soon as I > run it. > > To see all the steps I made I send a picture with the screenshots > showing all my actions until the error message appeared, log file that > cygwin created and the list of installed packages which I got after > typing "cygcheck -svr". > > If you need more information, feel free to mail me. > Thank you very much for you help. > > Best wishes, > Jaro Did you miss my reply? http://cygwin.com/ml/cygwin/2009-04/msg00010.html If you saw it, why did you not attach the output of "cygcheck -svr"? From your installed packages jpeg, the only mention of gcc is the gcc-testsuite. I.e. you haven't installed a compiler. BTW, posting jpegs is not the way to attach textual information. You should save the output to a text file, and attach the file. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange.
RE: edit Aux.pm under GNU emacs hangs
Marc Girod wrote: > Hi, > > I try to open a new file named 'Aux.pm' under GNU emacs, and this one > hangs. > Both in X and -nw modes. > > This is emacs 21.2.13 under cygwin 1.5.25-15. > > emacs works otherwise normally. http://cygwin.com/faq/faq-nochunks.html#faq.using.dos-filenames Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: no acceptable C compiler found in $PATH' error message on install
j.jovinbasil...@xxx.xx.xx wrote: > I am getting the above message when i run ./configure from the > extracted > gcc-4.3.3 directory. I have attached the cygcheck.out for your > reference. > > Let me know to get rid of this issue and to install verilog-perl on my > cygwin You have more than one problem, and one or more of them appears to have caused your installation not to be completed. From your cygcheck.out: > Warning: There are multiple cygwin1.dlls on your path This is always bad. Remove the ancient one from C:\WINDOWS\SYSTEM > Potential app conflicts: > > Sonic Solutions burning software containing DLA component > Logitech Process Monitor service > ZoneAlarm Personal Firewall These are all applications known to cause problems with cygwin. I suggest you read http://cygwin.com/faq/faq.using.html#faq.using.bloda Once you've resolved these problem, re-run setup.exe, just clicking next at each stage, and it *should* fix your installation. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: [openssh] unnatended instalation + forcing service account
Corinna Vinschen wrote: > On Apr 16 18:14, Julio Costa wrote: > > That's your call. For me it's fine either way. > > Thanks, I'll release a new openssh package shorty. ^^ shortly Fixed that for you (assuming you didn't intend to be derogatory about Julio's stature) Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: [ANNOUNCEMENT] Updated: rxvt-20050409-10
Charles Wilson wrote: > o Restore Alt-Space behavior (e.g. pass thru to windows, to > allow access to Minimize/Maximze/Restore menu). Reported > by Davide Dente. You say "restore", but I've never seen this behaviour in rxvt. Did it only make a transient appearance? Alt-Space is used in emacs for "just-one-space" which I use frequently. I can count on the fingers of zero hands the number of times I've ever wanted to summon the window menu using the keyboard from within rxvt. So, before I update and regret it, can this pandering to a Windows convention at the expense of *nix compatibility be disabled? If not, I consider this to be a major regression, effectively rendering rxvt useless for me. Cygwin is fundamentally about facilitating doing things the *nix way in a hostile Windows environment, not about compromising *nix applications in order to make them more friendly for Windows users. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: [ANNOUNCEMENT] Updated: rxvt-20050409-11
Charles Wilson wrote: > * Add -uas (--unixAltSpace) option to bypass Win32 handling > of Alt-Space key combination, and allow client (e.g. > Emacs) to handle it instead. Thanks for this Chuck. I can't see what in my previous post got you so worked up, and was a bit stung by your response. I can only assume that you must have misinterpreted my attitude. I certainly didn't intend to suggest that my own usage was typical, or that it was the only way that should be supported (I asked if it was configurable). I was only concerned that my usage pattern had apparently been overlooked. FWIW, I downloaded the source to work on a patch to do just this, but by the time I'd updated all my development packages and found my way around the source, you'd made your changes and posted the update. I guess I'll just have to find another itch to scratch instead. Thanks again, and for all your other recent hard work, which hasn't gone unnoticed. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: Moving Cygwin
Tim Visher wrote:
> Maybe the context for my question would help. I'm attempting to
> follow advice from [Steve Yegge's My .emacs File
> article](http://steve.yegge.googlepages.com/my-dot-emacs-file) in
> order to get useful cygwin bash interaction from within NT Emacs. He
> seems to be of the opinion that the gentleman who responded in the
> comments about having the path interpolation code and installing
> cygwin in the default directory was mislead about what you need to get
> it to work.
>
> Are there A) Practical responses to Yegge's way of using Cygwin and NT
> Emacs? or B) A proven way to do what I'm trying to do without messing
> with cygwin's install directory (I would prefer this as I would like
> to keep cygwin safely secluded).
I don't know what specific problems Steve Yegge had that made him think
he needed to install in C:\, but I have cygwin installed in the default
C:\cygwin and use bash without problem, including emacs correctly
tracking the current directory. There's certainly no need to install
cygwin into C:\
Using cygwin-mount.el, emacs understands cygwin paths. You can get
cygwin-mount.el here:
http://www.emacswiki.org/emacs/cygwin-mount.el
Install it into your site-lisp directory, and byte-compile it.
You can load a symbolic link, and emacs will open the target of the
link. The only thing I haven't figured out yet (without hacking the
C code) is how to get filename completion to follow symlinks, or to
load a file with a symlink in the middle of its path. I.e., if
/path/symlink.lnk points to /otherpath, you can load
/path/symlink.lnk, and emacs loads /otherpath, but you can't load
/path/symlink/file. (The symlink hack is likely to break with cygwin
1.7 if it uses utf-16 filenames for the symlink's target, so you
might just want to skip that part of the code).
The pertinent bits from my .emacs are:
8<
;;--- use bash as the default shell --
(setq shell-file-name "bash")
(setenv "SHELL" shell-file-name)
(setq explicit-shell-file-name shell-file-name)
(setq explicit-shell-args '("--login" "-i"))
(setq shell-command-switch "-ic")
(setq w32-quote-process-args t)
(defun bash ()
(interactive)
(let ((binary-process-input t)
(binary-process-output nil))
(shell)))
(setq process-coding-system-alist
(cons '("bash" . (raw-text-dos . raw-text-unix))
process-coding-system-alist))
;;
;; avoid problems with DOS line endings
(setq-default buffer-file-coding-system 'raw-text-unix)
;;-- teach emacs about cygwin mount points ---
(load-library "cygwin-mount")
(cygwin-mount-activate)
;;
;;--- let find-file follow a cygwin symbolic link
;; This doesn't work for filename completion, so we can only load the
;; file or directory pointed at by the .lnk file
(defun follow-cygwin-symlink ()
(save-excursion
(goto-char 0)
(if (looking-at "L\0\0\0\1\x14\x2\0\0\0\0\0\xC0\0\0\0\0\0\0\F\xD")
(progn
(re-search-forward "\x000\\([^\x000]+\\)$")
(find-alternate-file (match-string 1)))
(if (looking-at "!")
(progn
(re-search-forward "!\\(.*\\)\0")
(find-alternate-file (match-string 1
)))
;;
8<
The only other cygwin-related bit adds cygwin's info directories to
Info-default-directory-list.
It may not be important, but I use the vanilla NTemacs. If you use
Lennart Borgman's EmacsW32 and cannot get it to work, it's possible
that his patched version has gone too native. If so, try the unpatched
version. If the unpatched version works, I'm sure Lennart would be
interested to hear. He's very keen to ensure his version doesn't
break existing code. You can contact him via the help-emacs-windows
at gnu.org mailing list.
My ~/.bashrc contains the following:
8<
# set a simple prompt...
export PS1='\$ '
# ...and set the terminal's title (except when running in emacs)
if [ "$TERM" != "emacs" ];then
PS1U=`id -nu`
PS1H=`uname -n`
PROMPT_COMMAND='echo -ne "\033]2;`id -...@$ps1h:$PWD\007"'
fi
8<
Possibly significant system settings are:
/home is C:\home, set like this:
$ mount -f -s -b "C:/home" "/home"
HOME is a Windows _user_ environment variable, set to C:\home\
This means Emacs can find ~/
The system environment variable "Path" starts with:
"C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\usr\X11R6\bin"
I think that's all. (My .emacs is large and complex, so it's
possible I may have missed something).
Phil
--
This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange.
RE: system shared memory version mismatch
Polon Tang wrote: > When the problem appears, the error seems to complain about > cygwin1.dll version mismatch. [snip] > Is this a know issue? Is there any patch available to cure? Please > help. Many thanks. This is almost certainly because you updated cygwin without first terminating ALL cygwin processes. This includes any services you have started (I suspect you have cygserver running, but your version of cygcheck is too old to confirm this). You will have been warned that in-use files were replaced, and that you would need to reboot. That warning is there for a reason ;-) Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: mark-active (was: [1.7] Updated: {emacs,emacs-X11,emacs-el}-23.0.92-1)
Marc Girod wrote: > Two more changes I noticed with 23.0.92 (with respect to 21.2): > > 1. mark-active stays t after use (e.g. in the *shell* buffer), > with the result that the visual effect to mark the region gets > sticky. I can't help you here. I've not tried cygwin's 23.0.92 yet, but I can't say I've noticed this on Linux, although because I don't have transient-mark-mode turned on, I wouldn't really expect to. > 2. in a file buffer, doing C-x C-f (find-file) and RET will not read > the file again, but instead invoke dired. 'Twas ever thus. I think you're confusing C-x C-f with C-x C-v (find-alternate-file). The former has always* defaulted to the current directory. The latter has always defaulted to the current filename. [TIP: if you haven't already, try ido-mode. It redefines all buffer and file selection functions, and although it takes a little while to learn to get the most out of it, IMHO you'll quickly wonder how you managed without it.] [*] within my admittedly patchy memory. I *have* verified that 21.2.1 (the earliest version I have at hand) worked this way, on both cygwin and Linux. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: dialog ?
Markus Wenke wrote: > In early versions of cygwin, I've used "dialog" for some scripts. > Now I want to start the script and "dialog" is not installed on the > current cygwin version. > I tried to install it with Cygwin-setup, but I can't find a packet > named "dialog". > Which packet do I have to install for dialog? For this sort of question, you can either use the package search at http://cygwin.com/packages/ or simply use cygcheck: $ cygcheck -p dialog.exe Found 2 matches for dialog.exe. tetex-bin/tetex-bin-2.0.2-15The TeX text formatting system (binaries). tetex-bin/tetex-bin-3.0.0-3 The TeX text formatting system (binaries). In this case however, tetex-bin does not contain dialog.exe but tcdialog.exe. That file does seem to be dialog.exe by a different name though, so you might want to add "alias dialog=tcdialog" to ~/.bashrc This might be a packaging bug: typing "man tcdialog" brings up the dialog(1) man page, which suggests that something is not quite right. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: Can I speed up running "configure" script?
Ravenik wrote: > I type "./configure" in xterm to configure package. The script runs > very slowly - above 40 minutes. I suppose it should run faster on the > E8400 2x3GHz CPU. Can I speed up / boost this ? Windows Task Manager > shows "idle" process takes ~70%. Sorry if the question is stupid, I > am beginner at cygwin. > Host is Vista Home Premium 32, and cygwin is 1.5.25-15. Usually, when something takes this long, is not using 100% CPU, but is nevertheless progressing, it's because of network timeouts. Is it possible that you have a reference to a non-existent network share in your PATH? If not, you could try identifying where configure is spending its time by adding "set -x" near the top of the script (without the quotes, and after the line starting "#!".) That will slow things down even more, but as the output scrolls by, you might spot it taking longer than you'd expect somewhere. If you don't get anywhere, please follow the instructions here: > Problem reports: http://cygwin.com/problems.html particularly the bit about *attaching* the output from "cygcheck -svr" You might also check whether you're suffering from BLODA. See http://cygwin.com/faq/faq.using.html#faq.using.bloda and http://cygwin.com/acronyms/#BLODA Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: urxvt-X terminfo and Bash readline
Dan Moulding wrote: > The other odd thing I noticed is that for some reason in Bash the > readline functionality "horizontal-scroll-mode" defaults to "on" when > running inside urxvt-X. Normally this should default to "off" (as per > the Bash man page). When running Bash in an xterm window, it is set > "off" by default as expected. I had to manually turn it off in > .inputrc when using urxvt-X. > > Any comments are appreciated. I had this a month or two back when I was testing a new mintty release, I had updated "other stuff" at the same time. I thought it was a problem with mintty and had intended to report it, but I had to reboot before I'd fully investigated it. After rebooting, I was unable to reproduce the problem. Perhaps you just need to reboot too? NB, I didn't get any warnings about in-use files, which is why I hadn't already rebooted, so it's probably a more subtle issue than in-use DLLs. Phil -- -- 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: R: How to make cygwin redirect in UNIX mode?
Christopher Faylor wrote: > On Tue, Jun 09, 2009 at 10:27:27AM +0800, Pan ruochen wrote: > >> you installed cygwin in text mode. > >> So the output is DOS style, to have UNIX output > >> you need to install in binmode > > > >I did get one cygwin distribution which can excute scripts both in DOS > >mode and in UNIX mode and output in UNIX mode. The distribution is > >released in one install-shield package instead of numbers of gzip > >packages with a setup program in the traditional way. > > Whoa! Stop right there. If you got Cygwin from someone else then you > should go to the source for support. We don't support other people's > packages here. We support the version of Cygwin that you get from the > Cygwin web site. Theoretically this should not be too surprising. > > Please don't bother this list with questions about someone else's > distribution. Really. I mean it. Whoa! Careful with that knee-jerk! [*] I thought the point was that the "official" install didn't work, but that the 3rd party packaged version *did* work (presumably because it's using an ancient, line-ending agnostic bash, and has been installed with binary mounts) My advice to the OP would be to reinstall the official release, and this time make sure that "Unix/binary (RECOMMENDED)" is selected in the "Default Text File Type" section in setup.exe. That version you've installed is completely out of date. As soon as you try to update it, you're likely to run into far more problems than if you install a current version and keep it up to date. [*] just to be clear and avoid offense, that's "knee-jerk" as in the reaction, not "knee, jerk" which would have had a completely different meaning ;-) Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: find(1) assertion for folder with a sub-folder named `x:'
Corinna Vinschen wrote: > On Jun 19 17:55, Haojun Bao wrote: > > hi, > > > > Here's a test case to make find(1) assertion: > > > > mkdir no-such-dir/foo/bar: -p > > > > #this will not assert > > find no-such-dir/ > > > > mkdir no-such-dir/foo/c: -p > > I think the right answer here is "don't do that". Don't create files > or directories starting with a single character, followed by a colon. > The problem is that a path starting with "X:" is treated as an > absolute Win32 path. > > Right now you cannot have both. Either a path starting with "X:" is > treated as Win32 path, or Cygwin must stop handling Win32 paths at all > and only allow POSIX paths. Just to underline what Corinna said, consider the consequences of the following: mkdir -p foo/c: cd foo rm -rf c:/ In case you can't see why that's bad, DON'T TRY IT!! Don't even copy it, because you will accidentally paste it into a terminal window, you will get to say "oopsy!" [1], and you will hurt your forehead on your keyboard. If you can't resist the temptation, do invite friends round to watch; you'll have a humorous shared memory for later in life. Also consider videoing it, and getting a friend to post it on YouTube for you. [1] See http://www.theregister.co.uk/2008/10/03/bofh_2008_episode_32/ Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Tree command - Display Structure of Directory Hierarchy
There's a tree package available from here: http://lassauge.free.fr/cygwin/release/ I've no idea if this was the origin of the posted binary, but these packages DO come with source. I used to find these packages quite useful, but many packages had dependencies that conflicted with official cygwin packages' dependencies so I stopped using them. You should be OK with tree though. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: gcc4 and -mno-cygwin
Jerry DeLisle wrote: > You could try this: > > http://www.equation.com/servlet/equation.cmd?call=fortran Am I going blind, or is there no source available from there? Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Fonts look ugly in X with gvim
Steven Woody wrote on Tuesday, April 22, 2008 7:32 AM:: > Hi, > > I am using gvim in X window of cygwin. I selected a font Lucida > Typewriter same as I set for my windows version of gvim. Lucida > Typewriter looks good in windows version of gvim, but in cygwin's > gvim, it's ugly, looks like there is a space between every character > and the letters are very thin. Why's the wrong? My font setting > statement is, > > set guifont=Lucida_Sans_Typewriter:h17:cANSI You're trying to use the TTF version of the font. The Xft TTF renderer cannot use the hinting due to patent issues (unless you compile it yourself), which is why the X renditions are often relatively poor. If you really want to use the TTF version, you specify it in your .vimrc like this: set guifont=Lucida\ Sans\ Typewriter\ Semi-Condensed\ 17 You're better off using the PCF form of the font, which you do using: set guifont=LucidaTypewriter\ 17 I can't remember off hand which fonts are in which package, so you may need to install another package. You could also try Lucida Console, which is a similar monospaced font. > I also tried the Bitstream. When I use the menu edit->select font, I > selected the bitstream versa sans mono in the font selecting dialog. > This way it worked and the bitstream looked not bad ( I still need the > Lucida thought ), and when I type in > > set guifont > > in the command mode to see the font name, I got the font's name > > guifont=Bitstream Versa Sans Mono 18 ^ It's Vera > But the problem is I can not made this setting forever in vimrc file, > the statement > > set guifont="Bitstream Versa Sans Mono 18" You need to escape the spaces using backslashes. set guifont=Bitstream\ Vera\ Sans\ Mono\ 18 This is documented in vim's help (:help guifont) > will put the font settting back to its default, the guifont variable > was not set and became empty string. and, I also tried > > set guifont=Bitstream_Versa_San_Mono:h18:cANSI ^ ^^^ That's the OSX syntax, which is also documented in the help. Phil This email has been scanned by Ascribe Plc using Microsoft Antigen for Exchange. -- 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: fate/resolution/location of things like "sys/sockio.h"
Mike Marchywka wrote on Tuesday, May 27, 2008 2:53 PM:: > $ cygcheck ./pktdump_ex.exe | sed -e 's/ /./g' [snip] > ..C:\WINNT\cygwin1.dll ^ This is asking for trouble. Although it's probably nothing to do with the current topic, chances are that it's out of date and likely to be the cause of all sorts of spurious errors. The only cygwin1.dll on your system should be in /bin (aka /usr/bin) Phil -- One of the following statements is true: This email has not been scanned by Ascribe PLC using Microsoft Antigen for Exchange. This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: Cygwin compiler and linker options
John Emmas wrote on Friday, August 22, 2008 1:54 PM::
> Just doing some searches on the internet, there seems to be an awful
> lot of misinformation / misunderstanding about what the various
> Cygwin-gcc compiler and linker flags do.
>
> For example, I saw one article that said that that flag -mno-cygwin
> causes an executable to be generated which does *not* require
> cygwin1.dll to be present on the host machine. That doesn't seem to
> be true (I've tried it).
If you link with cygwin DLLs, it is the DLLs that require cygwin1.dll,
not the executable. If you compile with -mno-cygwin, do not link with
any cygwin DLLs. You wouldn't link with a cygwin DLL if you were
cross-compiling for Linux; the -mno-cygwin is essentially specifying
a cross-compilation for a cygwin-free architecture.
Think of it like this:
gcc -mvegan spaghetti.c -o meal -lparmesan
will not give you a vegan meal.
$ cat >hw.c <<'EOF'
> #include
>
> int main (int argc, char **argv)
> {
> puts ("Hello World");
> return 0;
> }
> EOF
$ gcc -mno-cygwin hw.c -o hw.exe
$ cygcheck ./hw.exe
.\hw.exe
C:\WINDOWS\system32\msvcrt.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
$ ./hw.exe
Hello World
$
I see no trace of cygwin1.dll in the cygcheck output.
> I saw another article which said that if you
> don't use the flag -mwindows, a DOS terminal will open every time you
> launch your app. That doesn't seem to be true either (at least, not
> on my machine).
How are you launching it? If you're doing it from a prompt, there's no
need to open another window. If you double-click on it in an Explorer
window, you WILL get a DOS box unless you specified -mwindows. Try the
above example and double click on it. You'll get a DOS box flash up
momentarily. Recompile using -mwindows, and you won't.
> Is there any resource available where I can find out some
> (authoritative) information about what the various flags actually do?
From the examples you've given, it seems you've already found some
authoritative information, but instead of doubting your ability to
comprehend, you've chosen to doubt the words of others and criticize
them in a public forum without providing any evidence to back up your
assertions. Not only is that arrogant, but now YOUR misinformation /
misunderstanding is out there to cause confusion for others.
It would be nice if the cygwin-specific options were documented in the
gcc info file, but they don't appear to be. Don't expect -mno-cygwin
to appear there soon either, because my understanding is that the
-mno-cygwin option will be removed soon because of the surprising
number of people who can't seem to grasp the concept of no-cygwin.
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: 1.5.25-15:bash failure with all basic commands
Phil Ten wrote on Tuesday, August 26, 2008 3:27 PM:: [snip] > > Attached cygcheck.out > > It reports > > "Warning: There are multiple cygwin1.dlls on your path" > > but I double checked and could find only one cygwin1.dll > on the server. > > Any help would be very appreciated. > > Phil Ten You should check your system PATH. You have C:\cygwin/bin, which is being interpreted by cygcheck as different from C:\cygwin\bin. This should consistently use backslashes. I don't know if this could explain your problem, but it seems possible given that strace seems to indicate a problem whilst processing your path. Phil This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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 --quiet-mode
Dave Korn wrote on Wednesday, September 10, 2008 7:22 PM::
> Rob wrote on 10 September 2008 19:03:
>
>> Since I'll be doing this upgrade on close to 100 boxes,
>> I've been trying to devise a *relatively* unattended process.
>> In case it helps anyone in the future, here's a snippet of my cmd
>> script I have so far:
>>
>> echo off
>> echo This will kill all cygwin related processes and update cygwin
>> echo Hit CTRL-C now to abort, otherwise:
>> pause
>> c:\cygwin\bin\bash.exe --login -c "ps -la|sed 's/^I/ /'|awk '{print
>> $4}'|grep - v WINPID >/tmp/pids.txt"
>> for /F %i in (c:\cygwin\tmp\pids.txt) DO taskkill /PID %i /F
>> del /F c:\cygwin\tmp\pids.txt
>> echo running setup...
>> \\fileserver\cygwin\setup-2.602.exe -q -L -l \\fileserver\cygwin -R
>> C:\cygwin echo Done
>
> That seems like a good start, but it's perhaps just a little bit
> crude in the way it handles services; if you kill them stone dead
> like that, the SCM will try and restart any that are set for
> auto-restart-on-fail. It would probably be a minor improvement if
> you add an extra bit of bash to shut them down gracefully by invoking
> cygrunsrv on them, something a bit like ...
>
> c:\cygwin\bin\bash.exe --login -c "cygrunsrv -L | xargs -n 1
> cygrunsrv -E"
>
> ... and only then carry on to brute-force kill the leftovers.
>
I don't know if this will work, but if you've around 100 boxes to
upgrade, it's probably worth investigating.
Instead of upgrading with the possibility of in use files, then
rebooting to fix any problems, why not attack it the other way round?
Install your script as a RunOnce task in the registry, then reboot.
The reboot will ensure there are no in use files, the script will
invoke setup (I think) before any services or normal startup tasks, so
you should be confident that setup will complete successfully, and not
require a second reboot.
Obviously, this will cause some unnecessary reboots, but this is
Windowsland where rebooting is a way of life; even Windows'
programmers never expected uptime to exceed 2^32 milliseconds.
Regarding the "setup not running postinstall scripts if there are any
in-use files" suggestion, could I suggest that this idea be modified
slightly?
Postponing all scripts could leave the system (prior to reboot) with
a package which was successfully installed, but not postinstalled, and
therefore potentially unusable when it could have been completely
installed. All that is necessary is to ensure that the packages'
dependencies are honoured when running their postinstall scripts.
This would ensure that as much as possible of the installation could
be completed prior to rebooting.
e.g. if package A depends on packages B and C, but a file from package
B is in use, package C can be completely installed and postinstalled,
but package A can only be installed. Running its postinstall script
must be delayed until after package B's postinstall script has run
following a reboot.
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
--
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: Access problems
Zarathustra wrote on Sunday, September 14, 2008 4:03 PM:: > I'm having some problems with certain executables in my cygwin > instalation. > Some executables (such as xgettext) issue an "Access is denied" > error. Any ideea on what's causing this? I'd wager you don't have permission to access something. Unlike your namesake, we're not blessed with divine insight (although Dave Korn occasionally makes me wonder), so if you want a more helpful answer, you need to post a *much* more helpful report: > Problem reports: http://cygwin.com/problems.html This link is attached to every post, but I notice that nabble in their wisdom remove it. This probably goes some way to explaining why a high proportion of inadequately reported problems seems to come from nabble users. As well as *attaching* the output of cygcheck -svr, you need to tell us what "certain executables" are. So we can see what it is trying to access, you should also attach the output of running: strace xgettext Also useful might be the output of the following commands: ls -l $(type -p xgettext) cacls $(cygpath -w $(type -p xgettext.exe)) cygcheck xgettext If you see "EACCES" in the strace output, look at the file that was being accessed and run the following commands on it: ls -ld filename cacls filename When including the output of commands, please use copy and paste, and include the output *in full*, otherwise you will almost certainly mistype something and/or miss out the important bit. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: g_assertions
John Emmas wrote on Monday, September 22, 2008 11:09 AM::
> Hi - I hope this is an appropriate place to ask this question. I'm
> just starting to use Cygwin. Firstly, the Cygwin web site says that
> the current version is 1.5.25-15 but my install log says that it
> installed 2.573.2.3 so I'm a bit confused about that.
2.573.2.3 is the version number of setup.exe, 1.5.25-15 is the version
number of the cygwin library.
> I'm now starting to compile a project using glibmm. Inside glib.h
> there are some assertions, defined something like this:-
>
> #define g_assert(expr) G_STMT_START{ \
> if (!(expr)) \
>g_log (G_LOG_DOMAIN, \
>G_LOG_LEVEL_ERROR,\
>"file %s: line %d: assertion failed: (%s)", \
>__FILE__, \
>__LINE__, \
>#expr); }G_STMT_END
>
> These compile perfectly with my gcc compiler but when I try to use
> them with Cygwin I get this error:-
>
> error: stray '\' in program
>
> It's pretty obvious why this is happening - but terminating a line
> with '\' is valid code.
I bet the obvious reason I'm thinking of isn't the one you're thinking
of. Your glib.h almost certainly has DOS style line endings, but the
header is on a UNIX mount. This means that the compiler sees a '\r'
after the \, which is NOT valid code.
You don't say where your glib.h came from, but I'd wager it's not from
the cygwin package. If you're compiling a cygwin program, you need to
install cygwin's glib2 package, and the matching glib2-devel package.
Had you *attached* the output of cygcheck -svr as requested here:
> Problem reports: http://cygwin.com/problems.html
It would have been easy to confirm that you were not using the cygwin
packaged glib.
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)
Dirk Napierala wrote on Thursday, October 09, 2008 10:51 AM:: > If I missed feedback to the thread below I have to apologize. > Otherwise I would like to recall this (my last post)again Please don't keep reposting the same message. You can google the mailing list archives if you think you may have missed a response. If you haven't, then consider that maybe no-one has anything useful to post, or perhaps no-one feels inclined to help you any more. It's your problem, yet you haven't exactly gone out of your way to help anyone get to the root of the problem. Simply rebutting all workaround suggestions with "can't do - corporate policy" has left me feeling that you're not really interested in solving your problem unless it means the SFX magically starts working. I think you have to assume that the problem is intractable. E.g. changes to cygwin1.dll may just require more memory than before, and it would be unreasonable to assume that an ill-conceived SFX would inspire anyone to undo those changes. If this is the case, then the SFX is broken, not cygwin1.dll. You therefore need to consider the alternatives. I had prepared an email with a couple of suggestions for you to try, but I didn't bother sending it because of your attitude towards the other responses. I suspect the rest of the list have also given up on you. Early on, you were asked to try some things that would have helped people to understand the cause of the problem but you were so reluctant to even try them that you can't blame people when they lose interest. If the issue is as important as your persistence suggests, I think you need to bang some heads at your workplace. If Oracle has such tight policies that you are unable to do your job, then the policies are just plain dumb (but then, so is using a single, huge SFX file). If you really do want help from the list: * Instead of just saying "can't do", tell us what you CAN do. * How EXACTLY is the SFX is run? * Does it use a fixed path? * Does it include the .exe extension? IIRC you said the SFX is run from a bash script that you can't modify. Why not? If you can read the script, you can surely copy it and change the copy. If you can't do that, and you can't regenerate the SFX file which is clearly incompatible (for whatever reason) with the latest cygwin DLL, you have a broken _system_, and someone in your company who does have the authority to make changes to that system needs to get involved. Phil -- 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: Powershell Ouput via Cygwin and Open SSH
Nick Calvert wrote on Monday, October 20, 2008 10:17 AM:: > Thanks very much Larry, even if i cant solve this issue i at least > know the cause. > > Sadly i cant find tfy.exe anywhere. I dont suppose anyone here still > has a copy? > You didn't look too hard. It took me only 1 minute to uncover this: http://sources.redhat.com/ml/cygwin/2006-03/msg00164.html The link in the message is still live. Phil -- -- 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: Incomplete installation of subversion
On 13 August 2010 11:27, Andrey Repin wrote: > Greetings, Corinna Vinschen! > >>> > On Thu, Aug 12, 2010 at 9:02 AM, Andrey Repin wrote: >>> > (snip) >>> >> :curl -iI -H "Accept-Encoding: gzip" -s -- >>> >> "http://cygwin.com/setup.exe"; >>> >> HTTP/1.1 200 OK >>> >> Date: Thu, 12 Aug 2010 06:59:40 GMT >>> >> Server: Apache/2.0.52 (Red Hat) >>> >> Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT >>> >> ETag: "18e01b8-a7413-9f101340" >>> >> Accept-Ranges: bytes >>> >> Vary: Accept-Encoding >>> >> Content-Encoding: gzip >>> >> Cache-Control: max-age=0 >>> >> Expires: Thu, 12 Aug 2010 06:59:40 GMT >>> >> Content-Type: application/octet-stream >>> >>> > Works for me with wget: >>> >>> Of course. It's just you can't launch it after wget - file don't have rights >>> to execute it. > >> chmod +x ? > > Indeed, yet again, it's not the point of my question. > I have download manager processing downloads from my web browser. > It's quite enough for me. When server behave correctly. There's nothing wrong (in this regard) with the server. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html | In HTTP, it SHOULD be sent whenever the message's length can be | determined prior to being transferred You forced it to use gzip encoding, which is often a streaming process, and in general a server won't know in advance how long the content will be. Remove the -H (and -I) and curl works just fine (and the content is shorter than the gzipped version). In fact, curl works just fine even with the -H option, as long as you remove the -I, and remember to gunzip the contents. You had the choice of: a) criticizing the set-up of one of the web's largest and most reliable download sites or b) pausing to consider whether perhaps you'd missed something in your HTTP class I think perhaps you made the wrong choice. Phil -- > > -- > WBR, > Andrey Repin (anrdae...@freemail.ru) 13.08.2010, <14:26> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
