Re: [ANNOUNCEMENT] Updated: vim-7.0.122-1
Dave Korn wrote: ... although I can see problems arising when someone uses mount to rename the cygdrive mount. Maybe it would be worth providing a notation that means 'cygdrive, no matter how it may have been renamed. Hmm, how about /dev/fs/? ;-) -- Matthew Will your shell have salvation? Only if it's Bourne Again. -- 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 1.5.21-2: ssh-add unable to connect to ssh-agent with McAfee installed
Tim Beuman wrote: Matthew, There is a line "Content-Disposition: inline" which causes the attachments to be shown inline. Could be the file-type that causes Thunderbird to add this line to the section header. I will check if I can convince Thunderbird to not include this line when sending .txt files. Hmm, yup, I bet that's it. See (1) for another example (note: I am also using Thunderbird). So, perhaps the question is why Jason complained in the first place, since this seems to be archive policy (and no one has complained at *me* for doing the same thing). Probably just overlooking "that's how the archiver works". :-) If you want to turn off "Content-Disposition: inline", that should be fine, but my impression is that some people prefer that to having to open attachments. :-) Maybe it would just be better if the archiver did like Thunderbird does and add an '' or something to delineate attachments from actual inline content (and I wonder, do these things then show up when you search the archives?). Would be nice if one of the big names would make an intelligible (2) comment on this. (1) http://cygwin.com/ml/cygwin/2006-09/msg00177.html (2) http://cygwin.com/ml/cygwin/2006-10/msg00410.html <-- not intelligible ;-) -- Matthew Will your shell have salvation? Only if it's Bourne Again. -- 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 1.5.21-2: ssh-add unable to connect to ssh-agent with McAfee installed
Larry Hall (Cygwin) wrote: mwoehlke wrote: Tim Beuman wrote: Hi Jason, The "Ridiculous amount of stuff" was sent out as atachments but I guess somehow it ended up inline. Sorry for that. Um... Huh. Thunderbird shows it as attachment. The web archive does not. Anyone that knows the mailer software have a guess what went wrong? Look at the raw message: <http://cygwin.com/cgi-bin/get-raw-msg?listname=cygwin&date=2006-10&msgid=452C15C2.4060800%40cdvinc.com> Not that I'm especially familiar with what I'm looking at, but that looked OK to me. Do *you* know who's dropping the ball here? Is Tim's mailer doing something funny or is the archiver not processing the message correctly? (I'm asking because either one should probably be looked into, although given that Thunderbird had no problems and the raw message looks OK to my eyeballs, it seems like the archiver ought to be handling this better than it obviously is.) (Since this is rather OT, is there a better place to discuss possible shortcomings of the mail archiver?) -- Matthew Will your shell have salvation? Only if it's Bourne Again. -- 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 1.5.21-2: ssh-add unable to connect to ssh-agent with McAfee installed
Tim Beuman wrote: Hi Jason, The "Ridiculous amount of stuff" was sent out as atachments but I guess somehow it ended up inline. Sorry for that. Um... Huh. Thunderbird shows it as attachment. The web archive does not. Anyone that knows the mailer software have a guess what went wrong? -- Matthew KDE: Desktop Excellence -- 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 1.5.21-2: ssh-add unable to connect to ssh-agent with McAfee installed
DePriest, Jason R. wrote: On 10/10/06, Tim Beuman <> wrote: I still have problems with ssh-agent/ssh-add when I install McAfee. Browsing over the internet didn't yield a working solution. Before I could stop McAfee and it would work but with the latest version of McAfee (version 10?) disabling McAfee doesn't make any difference anymore. Only an uninstall of McAfee makes things work again but this is not an option. A search of the mailing lists yielded other reports of the same problem but no real solutions. After some digging in the source I found that ssh-agent keeps waiting in the select for ssh-add to connect. For whatever reason ssh-add seems to be unable to connect to the AF_LOCAL socket created by ssh-agent. Attached the strace files from ssh-agent and ssh-add as well as the cygcheck output. DELETED Ridiculous amount of stuff that probably should have been in an attachment. Um, check again, there were about five lines other than what is quoted above (and those were 'hi' and a sig) that /weren't/ in attachments. :-) Good advice, though, hopefully it will help Tim. -- Matthew KDE: Desktop Excellence -- 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 ssh'd in, cannot run MS compiler /Zi debug option.
Michael Haubenwallner wrote: Mark Charney ieee.org> writes: I suspect I'm missing some "rights". This is an issue for me on multiple machines running Windows Server 2003 x64 or for 32b WinXP. When I try to compile using the debug-option (/Zi) to the Microsoft Visual Studio Pro 2005 compiler: cl /Zi hello.cpp it only works from within cygwin if I am on the console or remote desktop. If I ssh-in to the same machine, it fails with a error message: Fatal Error C1902: Program database manager mismatch; please check your installation. Just to be mentioned (did not find it on this list yet): There is a hotfix available from MS now (did not test myself yet): http://support.microsoft.com/kb/920770 Oh, they FINALLY dropped their "you have to give us a credit card before we'll tell you that we know about this issue" stance? Oh, wait, I see they didn't. Well, if you happen to either have this hotfix yourself or know where one can obtain it WITHOUT having to give Microsoft a credit card number, please let us know, and thanks anyway for the update. -- Matthew KDE: Desktop Excellence -- 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 a way to install old version cygwin?
Linda Walsh wrote: Eric Blake wrote: For example, it may just be a matter of figuring out which scripts have DOS line endings but reside on binary mounts. --- What was changed recently? Was it that the old, line-read functions quietly removed CR's so bash (et al.) wouldn't see them even on "binary" mounts? Any time you want to know "what changed recently", a good start is to look for the release announcement: http://cygwin.com/ml/cygwin-announce -- Matthew KDE: Desktop Excellence -- 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: Fatal error with PGREP
Sean McNamara wrote: Thanks for your response Matthew. I have attached my cygcheck output this time. Um... ok, we got it the first two times, you can stop posting it now. :-) Sorry for not doing that initially. Most mailing lists I subscribe to do not allow attachments, so I didn't think of doing so initially. Next time: http://cygwin.com/problems.html Also, I've reviewed the definition for TOFU, and am not sure I'm completely clear on where I went wrong other than possibly including the entire first email as a quote in the second, but will make sure that does not happen again. Well, that was it. TOFU: "Top over, fullquote under". You did both; included your entire original message, and also placed your reply above, where it is out of context. This time you left out context entirely. One could probably debate which is preferable. Oh, and also you might want to PCYMTWLL(*), and you *WILL* want to PCYMTNQREAIYR (or I can almost promise you you'll get yelled at ;-)). So far you've only done it to yourself. :-) Alternatively, do yourself a huge favor and try Thunderbird (www.mozilla.com). If you can't use it for e-mail, but have NNTP access, then you can go through news.gmane.org for this list (and many others). (*Apparently TB doesn't "actually" wrap - despite making you think it does in the composition window - but it doesn't cause the problems associated with 'bad' mailers that don't wrap, ala your post here: http://cygwin.com/ml/cygwin/2006-10/msg00347.html. Make your window horizontally small and observe the scrollbar.) -- Back to your originally-scheduled topic -- I also don't know why pgrep is not working; it WFM but 'pgrep sh' at a command prompt on a system not doing anything else isn't much of a test. Dave's suggestion sounded worth a try, or after it is in always-fail mode you could try debugging with gdb. -- Matthew "Try to bring it back in one piece this time." -- Q (MI6) -- 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: Fatal error with PGREP
Sean McNamara wrote: Hi all, I've been trying to resolve this for over a week, and there hasn't been a peep from the list. That has me wondering if: 1. Nobody has the slightest idea about what could be happening. 2. The solution is so painfully obvious that folks don't feel it warrants a response. While I'm hoping it's not #2, I will gratefully take my lumps if someone can point me in the right direction. Thanks! For starters, please stop PASTING your cygcheck output and start ATTACHING it. Then please stop sending http://cygwin.com/acronyms/#TOFU (following the first suggestion would have made the second less painful). -- Matthew "Try to bring it back in one piece this time." -- Q (MI6) -- 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: API versus web interface for public document access
Mike Marchywka wrote: Thanks, I've been on the list before and I do recall some related success stories. Any suggestions for a more appropriate audience? Since your question (which I read, after skimming through to find it at the bottom of your post) seems to relate generically to scripting, maybe a scripting forum (of which I do not know any to recommend). And, if you do find another audience, I would strongly recommend that you omit the background and post just the question, or at *bare* minimum have the question first, followed by all the examples. -- Matthew "Try to bring it back in one piece this time." -- Q (MI6) -- 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/
Reverting to older Cygwin installation?
I've been keeping up with the new make, bash, etc, on my own desktop, but I'd like to try updating our build machine's packages to see if we can get some speed out of the new bash release. However, this being a build machine, breaking it would be *bad*. I *want* to say I can downgrade (not uninstall and reinstall, downgrade) to the exact configuration we had by backing up the local install directory and - if needed - re-installing from there, but can someone confirm that this will (or at least "should") work? -- Matthew Don't use a hippo to... what was I saying? -- 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: spaces in .bash_profile lead to "command not found"
Peter Jay Salzman wrote: There are 4 blank lines in my .bash_profile: [snip] Each blank line generates an error: $ source .bash_profile BEGIN ~/.bash_profile : command not found : command not found : command not found : command not found END ~/.bash_profile However, if I comment all the blank lines out, I get no errors. Each blank line in this file seems to be causing a "command not found" error. What could be causing this? Have you eliminated CR's as the cause (RTFRA and STFLA if you don't know what I'm talking about). What version of bash are you using? It would be helpful if you read http://cygwin.com/problems.html, especially the part about ATTACHING (not pasting in-line) cygcheck output. (Ooh... google finds lots of "wrong" results for STFLA, but the second RTFRA is my big-nasty-rant one ;-).) -- Matthew Don't use a hippo to... what was I saying? -- 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 unix commands in windows
Dave Korn wrote: On 05 October 2006 08:52, Tom Lee wrote: is there a way to mount /cygdrive/c as /? by default, c:/cygwin is mounted as /. I really like the feature of "ls /" to display evevrything under c:/ If that's *really* what you want, i.e. you want all your unix/linux-style usr, lib, etc, bin, var (and so on) directories scattered amongst your win32-style "Documents and Settings", "Program Files", "WINDOWS" (and so on) directories in your C drive root directory, you should just install cygwin to C:\ instead of installing it to C:\cygwin by changing the default install location when you run setup.exe. Actually, if you don't mind sucking up precious mount points (doesn't Cygwin have a limit of 32 or something like that?), I would assume you can mount (ahem) EVERYTHING in C:\cygwin to the proper /bin, /lib, /etc, etc location and have / mounted as 'C:\'... but ooh that would be ugly. And don't ask me what problems it might cause... Better to listen to Eric's advice. -- Matthew Don't use a hippo to... what was I saying? -- 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.21: problem with source command in bash
Ring, Patrick wrote: I am having a problem with the "source" command in bash (3.1-9). When I try to source a file with aliases in it, the aliases get garbled so that they don't work. When I type "alias" on the command line, I can see that it is incorrect. Other commands also do not work, usually giving an error like "command not found". Example: Put the line alias ls='ls -F' in a file called trysrc. Inside bash, cd to the directory and type source trysrc alias I get the output 'lias ls='ls -F If I type 'ls', I get ls: invalid option -- If I type the alias command on the command line, it seems to work fine. I have also tried this on a second computer and get the same results. Thanks in advace for your help, Have you RTFRA'd (for bash-3.1-9) and STFLA'd? It looks like doing these would solve your problem. -- Matthew This message will self destruct in five millennia. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash and CR/LF line-endings
Williams, Gerald S (Jerry) wrote: Gary R. Van Sickle wrote: At the risk of being over-obvious, Linux users... use Linux. In such an insular environment, perhaps they have the luxury of only using the One True Text File Format (whatever that is). We're you the one who brought up Unicode earlier? Besides, there are numerous situations where files get transferred with without needing to involve Windows, so stray characters occasionally show up here and there. I'm sure many of us would like support for endings on Linux as well. ...which is exactly why I kept pestering Eric to know if he planned on submitting upstream. :-) http://cygwin.com/ml/cygwin/2006-10/msg00101.html (Eric's answer) -- Matthew This message will self destruct in five millennia. -- 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 scripts fail with bash3.1-8
Thomas Porschberg wrote: Am Tue, 3 Oct 2006 17:02:29 +0100 schrieb "Dave Korn" : On 03 October 2006 16:43, Turly O'Connor wrote: By way of an example as to what broke, note that in the following that "cleartool" is not a cygwin tool (it's a Windows executable), writing its CRLF-terminated output to Windows' stdout. CHECKOUTS=`cleartool lsc -all -cvi -s` # list all my checkouts I used to be able to do for one in $CHECKOUTS ; do echo $one Hello ; done C:/Path/To/file1 Hello C:/Path/To/file2 Hello Now it seems that "$one" above contains the binary CR, so I get: Hello h/To/file1 Hello h/To/file2 What do I need to do to get this working again? How about CHECKOUTS=`cleartool lsc -all -cvi -s | d2u` # list all my checkouts or for one in $((echo $CHECKOUTS | d2u)) ; do echo $one Hello ; done depending on how happy cleartool is on piping output to a cygwin program. This is exactly the problem I have with my sqlplus call. Is there a way to solve it without introducing the d2u filter ? You could try the new shopt... but have you considered arranging for 'sqlplus' to point to a shell script that would exec 'sqlplus.exe' and pipe it through d2u? -- Matthew This message will self destruct in five millennia. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc build problem - make vpath
Michael Eager wrote: [snip] Building gcc using the mozilla version of make-3.80 fails as previously described. I assumed that this version of make was the same as the one which I previously installed. Apparently, it isn't or there is some other incompatibility. Sounds like that might be a MinGW or Windows Native build, not a Cygwin build. If so that is probably the problem. The answer to my last question seems to be yes. (Thanks Matthew!) I'll look into using William Hoffman's patched version of make-3.81. Hope it works out for you! :-) -- Matthew "I don't question your existence -- God" (seen on a church billboard) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc build problem - make vpath
Michael Eager wrote: Dave Korn wrote: On 03 October 2006 03:10, Michael Eager wrote: It looks like make is not recognizing VPATH correctly. I'm using make-3.80-1. This is unlikely. Gcc is known to build on cygwin. I do it all the time and it has no problem for me. Perhaps something else is underlying. I've also built GCC on Cygwin a number of times without problem until I updated Cygwin, which installed make-3.81. The changes in make-3.81 cause problems with another makefile which uses DOS paths containing variables (%name), so I uninstalled make-3.81 and installed make-3.80 binaries from mozilla.org. I reinstalled make-3.81. The problem is gone. I don't have the option of re-writing the makefiles which use DOS paths to make them compatible with make-3.81. Is there a working version of make-3.80 available? Is there any option which will make make-3.81 treat DOS variables the same as in make-3.80? Oh, look, I *found* the link this time. :-) http://cygwin.com/ml/cygwin/2006-09/msg00315.html (Thanks, CGF! Alas, I have no link to where he provided the link :-).) -- Matthew "I don't question your existence -- God" (seen on a church billboard) -- 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: bash-3.1-9
Christopher Faylor wrote: On Tue, Oct 03, 2006 at 04:28:13PM +, Eric Blake wrote: mwoehlke writes: Eric Blake wrote: Second, this release adds a new shopt, igncr, which dynamically tells bash to ignore all \r in the input file when it is set; however, it defaults to unset. So, I keep wanting to know if you are thinking about submitting this upstream (or have you done so already?)... I'm hoping to port the patches to the 3.2 beta before proposing them upstream (right now, my cygwin TODO list includes: get coreutils 6.3 stable ported to cygwin, get bash 3.2beta ported to cygwin as experimental, post bash patches upstream, update bash-completion to use cygport and add some long overdue promised completion functions for cygwin). As written, my patch is conditionalized on __CYGWIN__, but when proposing it upstream, I will try to make it more generic. I really appreciate all of the time, thought, and effort you're putting into this, Eric. The Cygwin project is lucky to have you. What CGF said. And good luck with coreutils; I'm currently trying to build it across /my/ platform list (except for Cygwin which I leave in your capable hands). OSS should be fun... :-) -- Matthew "I don't question your existence -- God" (seen on a church billboard) -- 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: bash-3.1-9
Eric Blake wrote: Second, this release adds a new shopt, igncr, which dynamically tells bash to ignore all \r in the input file when it is set; however, it defaults to unset. So, I keep wanting to know if you are thinking about submitting this upstream (or have you done so already?)... -- Matthew "I don't question your existence -- God" (seen on a church billboard) -- 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: updated bash to latest 3.1.17(8)-release; startup has errors now
DePriest, Jason R. wrote: This google search was pretty much worthless when I ran it before I sent my message in: bash "command not found" site:cygwin.com inurl:ml If you've STFLA'd, it is good to mention this when asking your question. :-) vi did not show any unusual line endings (CR/LF) in /etc/profile before I sent my message in ...and you know to look for '(dos)' in the status line, right? Although as Larry pointed out, this is only reliable if vi[m] is configured a certain way; ultimately, you might want to just try running d2u on it regardless of what you *think* the line endings are. (Also, have you checked that there is not some OTHER script being called at login, say ~/.bash_profile, ~/.bashrc, etc) that has 'bad' line endings?) I noticed that the cygcheck output said things weren't there when a manual check shows that they are there and that they are in the path that cygcheck says it is checking. For my issue, not the thread hijacking 'make' issue, I do not have a dual-core or hyperthreaded system. Hint: that was satire. ;-) (And to explain/ruin the inside joke, 'make 3-81' was the previous problem-that-everyone-reported-without-RTFRN'ing) I did read the release notes when they came out. The ANNOUNCE list is the only one that I read all the messages for. It did not look like it should be causing the issues I am having. Ok, but again you should have mentioned that in your first e-mail... Otherwise, as you can see, people jump to the obvious conclusion. Plus, the more information you give off the bat, the more likely someone is to notice a problem and come up with a solution. -- Matthew "I don't question your existence -- God" (seen on a church billboard) -- 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: updated bash to latest 3.1.17(8)-release; startup has errors now
DePriest, Jason R. wrote: As I often do after an absence, I ran setup.exe on my system and updated my cygwin installation. After doing this, I get some wacky errors when I try to run a bash shell (double-clicking the cygwin icon). I don't know why I'm wasting my breath; no one that needs to read this is going to do so, but... Any time you upgrade a package and something that was working, stops working... *RTFRNBG*! In Cygwin's case, this means the ANNOUNCEMENT that went to cygwin-announce. And the SECOND thing you should do is STFLA for similar problems. In this case, looking for 'bash' in the last week of activity would have answered your question, or at least pointed you at a thread where you could contribute without looking like an idiot who doesn't know how to RTFRA or STFLA. (1: Read The (YKWGH) Release Notes Before Griping, also RTFRNBC (RTFRNBComplaining), RTFRN, and for Cygwin, RTFRA where A = ANNOUNCEMENT) (2: You Know What Goes Here) (3: Search The (YKWGH) List Archives) -- Matthew If this message is intercepted, the sender will disavow all knowledge of its existence. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Similar Bash 3.1.18 CR/LF Problem
Wilks, Dan wrote: So we just got the short-end? A long(?) standing behavior of cygwin and DOS paths and a recent change to bash that eliminates support for \r's. I guess we were living on the edge of something that wasn't supposed to work at all and didn't even know it. :/ We'll try to figure out some workaround for our environment. I just wish going "pure cygwin" was an option. Well, as we like to say here, http://cygwin.com/acronyms/#PTC. Since Eric is currently amenable to adding a shopt to bash, you have the option of implementing it yourself and submitting the patch for upstream consideration. -- Matthew My preferred shell is Christian. It's Bourne Again. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New windows from cygwin in ssh
Pavel Ivanoff wrote: Pavel Ivanoff wrote: The sshd service is running under my account. I go to Linux (via ssh). Then run ssh there, login onto my computer under my account, try to run any desktop program and it doesn't show any windows. My friend on another computer does all the same but with his account and his computer and desktop program shows all windows as expected. The differrence between our configurations: my - Windows XP, cygwin of 01.07.2006 (all standard packages) his - Windows 2000, cygwin of 01.03.2005 (all standard packages for that version) Why the behaviour is different? > my - Windows *XP* > his - Windows *2000* Have you considered this MAJOR difference? Yes, I considered it. [snip] Actually, your answer indicates you did not. Look again at the emphasis I added; it isn't pointing at the Cygwin versions. So my question is: this disabling of accessing to desktop is also new feature of new sshd? And can I allow him to access desktop somehow? Or I have to install on my computer the old sshd to become sure that old sshd will work on my OS too? You haven't clarified how you "know" that this is not caused by changes in how the OS treats the SYSTEM account, or service, or etc. between 2000 and XP. What is it: new security prohibition of Windows XP or new feature of last version of cygwin? My guess is "new security prohibition of Windows XP". Have you eliminated that? Unless you have evidence that this is not the case (meaning, one working and one non-working install /on the exact same OS/), why are you insisting that Cygwin and/or sshd is at fault? -- Matthew My preferred shell is Christian. It's Bourne Again. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New windows from cygwin in ssh
Pavel Ivanoff wrote: The sshd service is running under my account. I go to Linux (via ssh). Then run ssh there, login onto my computer under my account, try to run any desktop program and it doesn't show any windows. My friend on another computer does all the same but with his account and his computer and desktop program shows all windows as expected. The differrence between our configurations: my - Windows XP, cygwin of 01.07.2006 (all standard packages) his - Windows 2000, cygwin of 01.03.2005 (all standard packages for that version) Why the behaviour is different? > my - Windows *XP* > his - Windows *2000* Have you considered this MAJOR difference? -- Matthew My preferred shell is Christian. It's Bourne Again. -- 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 detection
Kenneth Nellis wrote:
Couldn't find anything relevant in the archives or the documentation...
I have bash scripts that I want to run identically under Cygwin and
Linux, which sometimes require the scripts to detect the environment
and branch accordingly. There are numerous ways to do Cygwin detection,
but I was wondering what technique should work with the widest audience
and be most immune to future Cygwin developments.
FWIW, below are various techniques that work for *me* *today*, some of
which have obvious flaws.
if [ -f /usr/bin/cygwin1.dll ]; then
if [ $CYGWIN_ROOT ]; then
if [ $OSTYPE = cygwin ]; then
if [ $(uname -s | grep -c CYGWIN) -gt 0 ]; then
if [ $(grep -c cygwin <<< ${BASH_VERSINFO[5]}) -gt 0 ]; then
if is_cygwin; then# where is_cygwin is a locally-built C program
# that tests #ifdef __CYGWIN__
Well, FWIW I've always used a combination of '#ifdef __CYGWIN__' and
uname (basically, the former when compiling C and the latter in
scripts)... of course, both of those are only really testing if gcc and
uname (respectively) are pointing at Cygwin versions. I would say that
99% of the time though 'uname' will work; basically it will only fail if
you have an Interix/MKS/MinGW 'uname' in PATH, but you can always check
for those as well to distinguish "real UNIX" from "UNIX on Windows". If
anyone builds a 'uname' on a Windows system that tells you 'Linux', they
deserve what they get. :-) I'd be inclined to say that anyone with a
system where 'uname' is wrong deserves to have things break.
If you *know* you are running bash, you can also check if it is MinGW by
testing if $BASH starts with '/' (at least, I assume it would be a DOS
path on MinGW, and MKS doesn't have bash). But this won't distinguish
Cygwin from Interix.
--
Matthew
My preferred shell is Christian. It's Bourne Again.
--
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: sqlplus and end-of-line problem in shell script code
Thomas Porschberg wrote: Hi, I want to use our shell script collection which includes sqlplus calls under Cygwin. I have the following problem with this code snippet: #!/bin/bash RESULT=`sqlplus -s myuser/[EMAIL PROTECTED] < Um, if by "the code" you meant the above script, then no. Otherwise it looks like you could drop a '| d2u' (or '| sed s/\r//g') in there. I forget though if you want: RESULT=`app | d2u << EOF input EOF` or RESULT=`app << EOF input EOF | d2u` ...or possibly neither. At any rate, that's a question of shell syntax; get that right and it seems it should work. -- Matthew My preferred shell is Christian. It's Bourne Again. -- 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 3.1.18 seems seriously broken
Eric Blake wrote: According to Eric Blake on 9/27/2006 7:02 PM: change the script to ignore whitespace (make the first non-comment line set IFS appropriately, as in this snippet: IFS=' '''' ' I retract this third suggestion. On investigation of the bash source, bash still treats \r as a non-IFS-whitespace, so while it has some effect, it is not a complete way to ignore \r\n line endings. I may still be able to add a cygwin-specific shopt for this, but recommend a text mount in the meantime if you are forced to use \r\n endings. While I still think this is probably the best solution (and should be less of a performance hit on binary, right? You still read buffered, and just discard '\r' in parsing, yes?), I wouldn't make it Cygwin-specific. At minimum, I /know/ this also affects Interix (and again, you should check with Rodney; I think he's already done half the work), and - being a shopt that has to be manually enabled - there might be a handful of people that would appreciate having this option on other UNIX's. Anyway, that's my $0.02... -- Matthew My preferred shell is Christian. It's Bourne Again. (Wow, appropriate signature for $RANDOM to pick :)) -- 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: reading directory .: No such file or directory
Lee Maschmeyer wrote: I've never had ls say it can't read ., but I do remember having path completion problems. I think that's why I use symbolic links instead of mount for drives; something like: cd / ln -s /cygdrive/c etc. Then I just cd /c and seldom have to use /cygdrive at all. I'm sure somebody will explain why this is a bad idea, which is one reason I'm responding here. But it does seem to muddle through... First reason it's a bad (or at least, dumb) idea: 'mount -c /' :-) As for the OP's problem, I think I saw someone else mention the exact same problem recently. Try searching the archives. -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. -- 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 3.1.17(8) CR/LF problem
Malcolm Nixon wrote: So why isn't using a textmode mount a solution? Packages generally contain the sources, build scripts, tools binaries, etc in a single directory tree. For example a ./configure script located in the package root directory along side other project files. As such placing just the bash scripts in a textmode mount would be virtually impossible. I trust someone else will chime in, but I thought this was not an issue? If a textmode mount can't have non-text, then it would be useless (and there would not be an option to make *all of cygwin* textmode in setup.exe, because nothing would work). Are you sure textmode isn't just applied to things opened (using the Cygwin libs) with "rt", and has no effect if you open "rb" (which is how I would assume it works)? -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? -- 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 3.1.18 seems seriously broken
Larry Breyer wrote: What changed from bash 3.1.17 to 3.1.18 ? Did you bother reading the ANNOUNCEMENT? I blindly performed a cygwin update, rebooted, and attempted startx. X came up OK but the terminals would not respond to keyboard input. Looking at the output of startx it became apparent something was seriously wrong with /bin/sh (/bin/bash). I got syntax errors on blank lines. I also found, by adding little debugging stuff, like 'ls $XAPPLRESDIR', that the shell was quoting env variables. I was getting "no such file or directory" on valid paths because the shell was including single quotes around the path. At least that's what it looked like. Really odd. I solved the problem by reverting to bash 3.1.17. -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? -- 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 3.1.17(8) CR/LF problem
Dave Korn wrote: On 27 September 2006 20:42, Malcolm Nixon wrote: In my opinion a better solution would have been to err on the side of compatibility and only use the new fast readline code if manually enabled. Then according to your opinion, everyone else in the world has to suffer from crippled bash performance because you can't be bothered to fix your systems. Better for /you/ maybe, but it's not always all about you. In MY opinion, a better solution would be to err on the side of efficency, and only use the old slow readline code if manually enabled. Right; non-standard behavior (and any non-binary treatment of '\r' certainly counts!) should - and I might dare even to say "must" - be disabled by default. Although in this case I can't think of any reason why you would ever have a '\r' in a shell script (other than as part of a line ending). Although if we make any of this optional, then IMO it needs to be done the right way, which is to just ignore '\r', at least at the end of lines. That way we can ALWAYS read in binary mode, and it isn't a major performance penalty. I suppose this would mean if it is turned on, scripts on textmode mounts will actually be faster because we can ignore the textmode. -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? -- 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 3.1.17(8) CR/LF problem
Jonathan Arnold wrote: Malcolm Nixon wrote: Unfortunately simply running "d2u" isn't a solution because: * Some revision control systems make the files read-only. I would venture to guess that *all* sccs make a file read-only. I know svn doesn't... rcs's that have a concept of "edit" usually will, but not all rcs's (again, e.g. svn) do. Not that 'chmod' won't fix this for you in a snap. -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? -- 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 3.1.17(8) CR/LF problem
Malcolm Nixon wrote: I recently updated to Bash 3.1.17(8) and found my local build system failing due to the removal of CR/LF support: "A script on a binary mount that uses \r\n line endings will probably encounter syntax errors or odd variable assignments, because the \r is treated literally. If this happens to you, use d2u to fix the line endings, or change your script to live in a text mount point. A script that resides on a text mount can have either line ending (even inconsistently mixed), but be aware that text mount points are slower, due to \r\n filtering." Unfortunately simply running "d2u" isn't a solution because: * Some revision control systems make the files read-only. * Some detect the change to as changes require manual merging. * Some translate files to a "Local" format (CR/LF on Windows). At least in some cases, there is a solution to this: use a Cygwin version of the RCS that knows that "native" means UNIX-style. :-) This works great for me (although I also go so far as specifying UNIX-style rather than "native"). I think the bigger issue here is that this arbitrary change will break a "significant" number of existing scripts. I contract for a few companies that use Cygwin/Bakefile to achieve support for multiple compilers/tool-chains, and for hourly auto-build servers. This change will break all of them - some of which have been functional for over 4 years. It won't break ours. Nor did make-3.81. We DIRTFT (Did It Right The First Time). :-) In my opinion a better solution would have been to err on the side of compatibility and only use the new fast readline code if manually enabled. I think a better solution would be to push for upstream to patch bash (probably as an option via shopt or an environment var or something) to just ignore '\r' at the end of a line. Interix has this problem also, and I think Rodney's version of bash does this (I know they went through this same issue, and the result was a bash that could always handle mixed line endings - I don't think Interix has any concept of a 'text mode' mount so it sees scripts like a UNIX would). -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? -- 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: make 3.81-1 problems with DOS-paths
Knut Schwichtenberg wrote: I've udated on 14.Sep.06 my Cygwin make to 3.81-1. The C-project I was compiling generated dependency files including system files. For system files the full path in DOS notation is entered into the dependency file. Make stops the execution of the makefile with the "very" expressive message: "multiple target patterns. Stop." Digging around with gdb and the source code I found out a missing define at compile time of make. The define "HAS_DOS_PATHS" was not set in the makefie for make. Version 3.80 of make ran without problems and setting this switch makes 3.81 run without a problem. How is it possible that ./configure does not recognize the Cygwin environment properly for a Windows-PC? Is the missing define only a derived problem that is based on an error in the toolchain before? If you'd STFLA'd (LA = List Archives), you'd know that this was the subject of Cygwin's most recent Holy War. IIRC "HAS_DOS_PATHS" is a broken solution, which is why it was not (and as I understand, never was) defined for Cygwin. Instead there was a kludgy patch in place that CGF decided to stop maintaining (which generated a lot of irate users... and a new upstream patch, which I thought was in the latest available package?). So if someone that knows what the status of said package would kindly step in now? (Or you can STFLA...) In short: make 3.81 intentionally removed support for DOS paths; use make 3.80 or the newer version (make-3.81-2?). -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? -- 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 problem - v3.1.17(8) - syntax error
Arun Biyani wrote: I just upgraded to the current bash. Now I am getting an error. I reinstalled, rebooted the machine. Still get the same error. The variable $HOME is set correctly. > bash: /c/home/abiyani/.bash_login: line 7: syntax error: unexpected end of file > > [EMAIL PROTECTED] ~ > $ bash --version > GNU bash, version 3.1.17(8)-release (i686-pc-cygwin) > Copyright (C) 2005 Free Software Foundation, Inc. > > [EMAIL PROTECTED] ~ > $ cat ~/.bashrc > # > if [ -f $HOME/wrk/sys/com/bash_more ] > then > . $HOME/wrk/sys/com/bash_more > fi > # > > > [EMAIL PROTECTED] ~ Just for the record, the release announcement did mention: "A script on a binary mount that uses \r\n line endings will probably encounter syntax errors or odd variable assignments, because the \r is treated literally. If this happens to you, use d2u to fix the line endings, or change your script to live in a text mount point. A script that resides on a text mount can have either line ending (even inconsistently mixed), but be aware that text mount points are slower, due to \r\n filtering." -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. -- 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 filesystem
Dave Korn wrote: On 18 September 2006 19:37, Francis Rossi wrote: As would mounting and/or deleting a separate Windows partition, no? No, because the virtual Cygwin partition would be one Windows file. One file is much easier to delete than the whole C: drive, isn't it? Two words: Quick Format. For some reason this makes me want to go *honk* ;-) I'm not sure why, but *snort* just doesn't seem as appropriate. :-D -- Matthew KATE: Awesome Text Editor -- 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: MINGW GCC WIN64 port?
Christopher Faylor wrote: On Mon, Sep 18, 2006 at 01:26:31PM -0500, mwoehlke wrote: William Deegan wrote: This may be a little off topic, but I beleive there's enough of an audience here to make it worthwhile. One of my clients is interested in getting MINGW working on win64. We're considering engaging codesourcery to do the work. Anyone out there interested/able to co-funding the work? For the record, I know I saw something somewhere within the last month or two about binutils adding support for win64, which is a major part of this project. If you aren't the person that made the announcement I am thinking of, you might want to be careful about not duplicating work that someone else is already doing. (I'd have to think that whoever is working on it already would appreciate help, however.) The patch has been submitted so I think the only help required is to test it. The discussion is going on in the binutils_AT_sourceware_PERIOD_org mailing list. I was also thinking of gcc/gdb (and of course ironing out bugs in the various ports, i.e. Cygwin, mingw, Interix); my impression was that what was "done" (at least when I heard) was just binutils and gcc/gdb would be the next steps. Maybe I'm wrong? Anyway, we are certainly in agreement that Bill's main effort should be to test/improve what is already done rather than re-invent the wheel. Thanks for the link (and for reminding me where I saw this). :-) -- Matthew KATE: Awesome Text Editor -- 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: MINGW GCC WIN64 port?
William Deegan wrote: This may be a little off topic, but I beleive there's enough of an audience here to make it worthwhile. One of my clients is interested in getting MINGW working on win64. We're considering engaging codesourcery to do the work. Anyone out there interested/able to co-funding the work? For the record, I know I saw something somewhere within the last month or two about binutils adding support for win64, which is a major part of this project. If you aren't the person that made the announcement I am thinking of, you might want to be careful about not duplicating work that someone else is already doing. (I'd have to think that whoever is working on it already would appreciate help, however.) Personally, I don't think it's off-topic; 64-bit Cygwin (which is primarily a matter of adding win64 support to binutils, gcc and gdb, at least as far as those being the biggest hurdles) is a topic that's bounced around before, and as you say, I think a number of people here would be interested in news of the progress of such a project. -- Matthew KATE: Awesome Text Editor -- 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-3.1-7 bug
Christopher Faylor wrote: On Wed, Sep 13, 2006 at 06:09:03PM -0700, Volker Quetschke wrote: Christopher Faylor wrote: On Wed, Sep 13, 2006 at 04:46:28PM -0700, Volker Quetschke wrote: (snip) Do I have to make the observation again that whether this is the case or not, it is not a primary goal of the Cygwin project to support these people? Yes. Did it ever cross your mind that the whole "Linux on Windows" thing is pretty useless if it cannot be used in the "real world". Death of Cygwin predicted? Everybody panic and/or sip? ...As much as I agree with Volker's assertion (one user using Cygwin as a unix-like front-end for cl.exe, right here - although you'll recall that I'm also one of the ones that understands what Cygwin wants to be and never got tripped up by make (though in all honesty I haven't upgraded yet ;-) but only because I really don't like messing with a working build machine, and if 3.81 broke it would certainly be *my* fault))... I mean, if people want to have a plain vanilla Linux thingy they can just install it. Grab a Redhat, Suse or Debian DVD and everything works fine. I suspect that the "Well, they can just install Linux (floppies, CDs, DVDs) if they feel like it" observation has been made several times a year for the last ten years. It's obviously not a very powerful argument since Cygwin is still here and you can't really assert that the only reason it is here is because make understood MS-DOS paths or bash dealt properly with \r\n line endings. I doubt that Eric will want to deal with the fallout of having bash not understand \r\n line endings but, if he does, it would be his decision and, again, I would support it 100%. I am very eager to see things like configure scripts work faster and if we have to drop a few scared or lazy people along the way to accomplish that goal, that's fine with me. I have no problem at all with being a part of a smaller community which doesn't need to use notepad to edit their bash scripts. ...I have to agree that this is a different case. Changing makefiles that used DOS paths is one thing; you can make them work (like I do, by doing things 'right' in the first place), but if you've built a system on makefiles relying on DOS paths, fixing them can be painful and error prone. Whereas 'dos2unix
Re: bash-3.1-7$B!!(BBUG
Eric Blake wrote: mwoehlke tibco.com> writes: Would it be possible to do this dynamically (instead of keying off of mounts, etc.): if the first line of the file read by bash has a \r\n, use text-mode (1-char-at-a-time) semantics, else use binary semantics (lseek)? I hate to say this, but... if bash goes this route, could it be a shopt? I would rather know that my scripts are broken (DOS-format). Thanks for the ideas; here's what I'll try. Bash does indeed already scan the first line (I'm not sure if it is line or first 80 characters or what it is exactly, but I do know it scans) to see if it detects any NUL bytes, at which point it complains the file is binary and not a script. So I can probably hack that scan to also look for \r. So first I will open the file according to the mount point rules. If the file is text mode, perform the scan in binary mode, and if any \r is seen, revert to text mode and no lseeks. If the scan in binary mode succeeds, then leave the file in binary mode, assuming that the file is unix format even though it is on a text mount, and that lseeks will work. If the file starts life binary mode (ie. was on a binary mount), skip the check for \r in the scan (under the assumption that on a binary mount, \r is intentional and not a line ending to be collapsed), and use lseeks. No guarantees on whether this will pan out, or be bigger than I thought, but hopefully you will see a bash 3.1-8 with these semantics soon. Sounds good! That will satisfy my request to not silently work on files that should be broken. :-) Alternatively (and I kind-of hate to say this :-)), now that I think of it, you might want to talk to Rodney over at the Interix forums. I recall hearing that the Interix version of bash actually handles files with a mix of DOS and UNIX line endings (which may not be the best thing to do, but might be worth investigating). I would imagine that version is always reading in binary (I don't think Interix - like UNIX, but unlike Cygwin - ever had a 'text mode' concept). There might even be an official patch for this, that just needs to be flipped on for Cygwin (or maybe the two of you can petition to make it an official patch). -- Matthew 41% of all statistics are made up on the spot. -- 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 of cygwin unsuccessful
Michael Pusch pasted cygcheck output... Dave Korn wrote: Give that a go and send your cygcheck results as an attachment. In the future, please remember to *attach*, not paste. :-) -- Matthew 80% of all statistics are made up on the spot. -- 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-3.1-7$B!!(BBUG
Shankar Unni wrote: Eric Blake wrote: But I intend that on binary files, \r\n line endings will treat the \r as part of the line, so at least binary mounts won't suffer from the speed impact of treating a file as unseekable the way bash 3.1-6 does. Would it be possible to do this dynamically (instead of keying off of mounts, etc.): if the first line of the file read by bash has a \r\n, use text-mode (1-char-at-a-time) semantics, else use binary semantics (lseek)? I hate to say this, but... if bash goes this route, could it be a shopt? I would rather know that my scripts are broken (DOS-format). -- Matthew 62% of all statistics are made up on the spot. -- 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: Mount does not show Samba files
Arun Biyani wrote: [download$:575] ls //goddard/y ls: //goddard/y: No such file or directory [download$:576] ls //goddard/abiyani ls: //goddard/abiyani: No such file or directory [download$:577] Larry Hall (Cygwin) wrote: what does 'ls /cygdrive/y' say? You didn't answer this, and it may be relevant. (That, or you typo'd in your previous message :-).) -- Matthew Ok, so the quotes aren't entirely original. -- 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 [experimental]: bash-3.1-7
Eric Blake wrote: mwoehlke tibco.com> writes: So $HOME is being set wrong. "echo $HOME | od -c" gives " / h o m e / m w o e h l k e \r \n". "echo %HOME%" from a fresh cmd.exe gives "C:/Documents and Settings/mwoehlke". I ran d2u on /etc/profile, /etc/default/etc/profile and /etc/passwd. I can't reproduce this. Have you tried 'bash -lvx' for a verbose trace, to see if some text-mode file is being sourced very early in your edited /etc/profile which does HOME=/home/mwoehlke? The fact that Windows %HOME% is defined differently than what you want in cygwin makes it seem like you are doing something in /etc/profile to override what cygwin would normally do for $HOME. I tried 'bash -x'. Alas I stupidly did it when already in bash (hey, my non-bash shells are hard to get to! ;-)). I did finally track it down; mwoehlke/.bash_profile in c:/documents and settings was DOS-format, and was re-invoking bash -l after changing HOME. I'm not sure how *that* wound up in DOS format; must've used Notepad the one-and-only time I edited it. Sorry for the trouble. :-) POSIXLY_CORRECT = '1' <-- what is setting this, and why? That is being set by cygcheck, just before invoking external programs. It probably had something to do with forcing external programs to not rearrange option arguments (for example, "ls foo --all" treats --all as an option, but "POSIXLY_CORRECT=1 ls foo --all" treats --all as a filename). But I think it is possible to get along without doing it (repeating the example, "ls -- foo --all" treats --all as a filename), and I personally think that cygcheck should be patched to QUIT setting POSIXLY_CORRECT, so that we can tell the masochists apart from normal users. Ah, ok, so seeing it in cygcheck is a false positive. Didn't think that cygcheck would tinker with my environment (maybe it should know it is doing so and preserve the invocation value and print that?), so I didn't think to actually 'echo $POSIXLY_CORRECT'. :-) IOW I agree with your suggestion. I just got a little freaked out thinking that Cygwin had unwittingly *made* me one of said users. ;-) -- Matthew KATE: Awesome Text Editor -- 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 [experimental]: bash-3.1-7
Christopher Faylor wrote: On Mon, Sep 11, 2006 at 01:04:30PM -0500, mwoehlke wrote: Eric Blake wrote: NOTICE: === This version removes several outdated #defines that were once necessary in older versions of cygwin, but which made bash on cygwin different and slower than bash on Linux. In the process, there is a major change in behavior - bash no longer forces text mode when reading scripts. If your script resides on a text mount point, you will not notice any difference. If your script resides on a binary mount point, and has normal unix \n line endings, you may notice a slight speedup. But if your script resides on a binary mount point, and has \r\n line endings, bash will most likely encounter syntax errors. The fix is simple - use d2u to convert script files residing on a binary mount point to be unix files, or if you must use DOS lines, use a text mount point. Because of this change in behavior, I am marking this version experimental for a while until I can gauge from mailing list traffic that it is safe to promote to current. When starting the experimental version with "c:\cygwin\bin\bash.exe -l". I get: mkdir: cannot create directory `/home/mwoehlke\r': No such file or directory Copying skeleton files. These files are for the user to personalise their cygwin experience. These will never be overwritten. /usr/bin/install: cannot create directory `/home/mwoehlke\r': No such file or directory /usr/bin/install: cannot create directory `/home/mwoehlke\r': No such file or directory /usr/bin/install: cannot create directory `/home/mwoehlke\r': No such file or directory : No such file or directory [EMAIL PROTECTED] /etc/skel $ So $HOME is being set wrong. "echo $HOME | od -c" gives " / h o m e / m w o e h l k e \r \n". "echo %HOME%" from a fresh cmd.exe gives "C:/Documents and Settings/mwoehlke". I ran d2u on /etc/profile, /etc/default/etc/profile and /etc/passwd. If I 'export HOME=/home/mwoehlke', then things work correctly. Somehow, before /etc/profile is executed, my $HOME is being set "funny". Any guesses? Does your /etc/passwd contain \r\n line endings? No... I ran d2u on /etc/profile, /etc/default/etc/profile and /etc/passwd. Besides, $HOME is colon-separated, with data after it, so even if it does/did, it seems like something else would be going wrong if this caused $HOME to have a '\r' on the end. I don't think this is the answer, but I'm attaching a new cygcheck output just in case. -- Matthew KATE: Awesome Text Editor Cygwin Configuration Diagnostics Current System Time: Mon Sep 11 13:17:44 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\opt\qt\3.3\bin C:\cygwin\opt\kde3.4\bin C:\cygwin\opt\kde3.4\lib C:\cygwin\opt\kde3.4\lib\kde3 C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\cygwin\opt\qt\3.3\bin C:\cygwin\opt\kde3.4\bin C:\cygwin\opt\kde3.4\lib C:\cygwin\opt\kde3.4\lib\kde3 C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\mks\mksnt c:\PROGRA~1\Oracle\jre\112EBD~1.7\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Dev\Perforce c:\SFU\common\ [snip] [snip] [snip] c:\Program Files\QuickTime\QTSystem\ c:\Dev\Common\Tools\WinNT c:\Dev\Common\MSDev98\Bin c:\Dev\Common\Tools c:\Dev\VC98\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 1051(mwoehlke) GID: 513(None) 0(root) 513(None) 544(Administrators) 100(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1051(mwoehlke) GID: 513(None) 0(root) 513(None) 544(Administrators) 100(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'mwoehlke' PWD = '/etc' CYGWIN = 'tty' HOME = '/home/mwoehlke ' <-- oops! MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\mwoehlke' APPDATA = 'C:\Documents and Settings\mwoehlke\Application Data' MANPATH = '/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man:/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man:/opt/qt/3.3/doc/man:/usr/X11R6/man:/usr/ssl/man:/opt/qt/3.3/doc/man:/usr/X11R6/man' HOSTNAME = 'Harkness' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 6 Stepping 2, AuthenticAMD' SHELL = 'C:/mks/mksnt/sh.exe' <-- doesn't seem to be it, I unset this to no effect (and also fixed it, but that won't pick up until reboot) TERM = 'cygwin' WINDIR = 'C:\WINDOWS' TMPDIR = '/cygdrive/c/WINDOWS/TEMP' KDEHOME = '/opt/kde3.4/home' OLDPWD =
Re: [ANNOUNCEMENT] Updated [experimental]: bash-3.1-7
Eric Blake wrote: NOTICE: === This version removes several outdated #defines that were once necessary in older versions of cygwin, but which made bash on cygwin different and slower than bash on Linux. In the process, there is a major change in behavior - bash no longer forces text mode when reading scripts. If your script resides on a text mount point, you will not notice any difference. If your script resides on a binary mount point, and has normal unix \n line endings, you may notice a slight speedup. But if your script resides on a binary mount point, and has \r\n line endings, bash will most likely encounter syntax errors. The fix is simple - use d2u to convert script files residing on a binary mount point to be unix files, or if you must use DOS lines, use a text mount point. Because of this change in behavior, I am marking this version experimental for a while until I can gauge from mailing list traffic that it is safe to promote to current. When starting the experimental version with "c:\cygwin\bin\bash.exe -l". I get: mkdir: cannot create directory `/home/mwoehlke\r': No such file or directory Copying skeleton files. These files are for the user to personalise their cygwin experience. These will never be overwritten. /usr/bin/install: cannot create directory `/home/mwoehlke\r': No such file or directory /usr/bin/install: cannot create directory `/home/mwoehlke\r': No such file or directory /usr/bin/install: cannot create directory `/home/mwoehlke\r': No such file or directory : No such file or directory [EMAIL PROTECTED] /etc/skel $ So $HOME is being set wrong. "echo $HOME | od -c" gives " / h o m e / m w o e h l k e \r \n". "echo %HOME%" from a fresh cmd.exe gives "C:/Documents and Settings/mwoehlke". I ran d2u on /etc/profile, /etc/default/etc/profile and /etc/passwd. If I 'export HOME=/home/mwoehlke', then things work correctly. Somehow, before /etc/profile is executed, my $HOME is being set "funny". Any guesses? -- Matthew KATE: Awesome Text Editor -- 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 fork()
Brian Dessent wrote: "Gary R. Van Sickle" wrote: AFAIK, Cygwin's lseek should handle seeking on text streams. DJ implemented that years ago. Last I looked, which was admittedly also years ago, it was "#if 0"'ed out, with a comment to the effect of "Nobody has any business seeking around in text files." FWIW, mingw's lseek() (which is actually Microsoft's, since mingw targets MSVCRT.DLL) is horribly broken when seeking on a file opened in text mode. But it's documented as such on MSDN, so at least there's that. So there is some precedence for the concept that "this won't work on windows platforms." But Cygwin's should work fine, and if it means saving a bazillion 1-byte syscalls then I think bash should be patched to remove this sillyness ASAP. I'll *emphatically* second the 'doing something about it'; I'm also cursed by really slow builds. (Assuming I understand what is going on, anyway :-)) -- Matthew Do not expose to hippos. Doing so may void your warranty. -- 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: nfs in client mode (winxp => linux)
[EMAIL PROTECTED] wrote: I see lots of past messages here about setting up NFS in server mode, but very little in the other direction. Going far enough back there was quite a long thread about SFU (Services for unix) but I haven't been able to get that NFS client to work. In fact I can't even really do anything with ksh shell it provides. Every command gets a tty error. So has anything changed since the release of SFU 3.5? That has been a good while. Is there still no cygwin NFS client for windows? I use both SFU (3.5, pre-2003R2) and SUA (5.2, Win2003R2 and later) NFS clients without too much trouble (nothing that doesn't seem to be general sharing problems, anyway; mostly it works about as well as anything over ssh - i.e. poorly). The trick is getting user name mapping set up correctly. You might want to ask on the Interix forums (http://www.interopsystems.com/tools/default.aspx) if things aren't working. Unfortunately there is no NFS client (not that I've ever heard of, anyway) that plays nicely with Cygwin (true symlink and permissions support, for example). -- Matthew Do not expose to hippos. Doing so may void your warranty. -- 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: Color Schemes
George wrote: On Thu, Aug 31, 2006 at 12:59:09PM -0500, mwoehlke wrote: George wrote: On Thu, Aug 31, 2006 at 09:44:51AM -0500, mwoehlke wrote: Dave Korn wrote: [...] and I am not aware of any way to examine the terminal's "palette", nor should you need to. If a user wants to fiddle with these, it is his responsibility to keep things legible. $ grep color ~/.Xdefaults [...] Or am I missing something? Sure. Now do it for Konsole (hint: DCOP *might* let you), CUI, Console, rxvt, PuTTY, and every other terminal emulator in existence. I guess I don't understand why one would expect that to be possible, or desirable. Exactly. I don't expect it to be possible, nor do I see a purpose for it. Which is why I wondered why you went digging for how to do it with xterm. :-) So I guess we are in violent agreement? What you found is the *default* colors for *one* emulator (what happens if you override them with command-line switches?). No, those are my colors (the default colors are very different) and are used by any emulator that makes uses of .Xdefaults, which includes rxvt and standard xterms. Command-line switches for both are mostly in a one-to-one correspondence with the directives in .Xdefaults. "Defaults" as in "unless command-line args are used to override them". I did notice that they looked decidedly 'non-standard'. :-) Dave and I were talking about being able to query the terminal emulator in a standardized way, and I am pretty sure there is no such way. Sorry for the noise. Eh, don't worry about it. Now I know where to tinker with rxvt's "default" settings. :-) Never know who might get something out of this... -- Matthew Do not expose to hippos. Doing so may void your warranty. -- 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.21: fork in find/ls failing, simple test case
John Hartman wrote: Okay, when I stopped the 'Logitech Process Monitor' service the problem goes away. Thanks for the quick diagnosis. [snip] Can you tell me what the root cause is? Logitech's drivers suck? :-) You might want to search the archives for 'logitech', just to see what other problems people have had. -- Matthew We apologize for the inconvenience. -- 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: Color Schemes
Aha!
Clicking on the icons and spinning the number wheels is NOT the same
thing at all! :-(
Right.
The real issue I'm having as the naive user is the colors dialog GUI
human interface.
...and for the record, I hate that UI. :-) It isn't very well designed IMO.
[snip]
As I understand it, the OS thinks it is still using white-on-black,
but cygwin is mapping those to white-on-black in the drawing routines.
Right?
Um, yeah, something like that. The tty knows what color codes it is
using ('0;30' - '0;37' and '1;30' - '1;37'), which have "standard"
colors assigned to them, e.g. '0;30' is "black", but you are correct
that if you change the mapping, the underlying programs (ls, man, etc)
don't know that you have done so.
Whereas before, I was changing the very definition of "black" to be
255,255,255 and white to be 0,0,0 -- and that just confused the heck
out of the OS. Right?
I think what you were doing before was telling the OS to use '1;37' as
the default background color, which confused the heck out of
applications that expected it to be '0;30'.
This was not at all clear from the layout and the controls.
What's more, there's a real goofy disconnect here between all the
OTHER colors that can be affected.
Right, it is not a very intuitive system. (Time to plug Console again;
it has the same features but is less confusing.
http://sourceforge.net/projects/console/)
For example:
After re-setting the background to 0,0,0 and foreground to 255,255,255
and then choosing the white icon for background and black icon for
foreground, 'man man' was much better.
I found that the grey color of args and such-like, however, was too
difficult to read.
So I wanted to alter the 128,128,128 color to a darker greyscale value.
To do that, I have to click on the color icon, which changes whatever
radio button is selected at the top, then muck with the numbers to
alter the underlying values of "grey" to a different "grey", then
click back on another color icon to get what I want for the radio
button.
In other words, editing the palette has been inextricably linked with
altering foreground/background, and it's quite a confusing
non-intuitive jumble of two different activities:
Right. To edit the mapping ("palette"), you have to pick a color...
which changes the default code used for background (or whatever radio is
selected), edit the color, and then re-select the previously-selected
color. It's a bad design.
#1) Altering the colors selected for 4 visual elements, out of dozens
of visual elements that are actually in use in the underlying OS.
#2) Altering the very definition of individual colors like "black" to
be something other than 0,0,0
This is not all just a rant -- I'd really like to suggest a better
alternative.
[snip]
http://sourceforge.net/projects/console/ :-)
Otherwise, you're complaining about a Windows component and need to
bitch to Microsoft (and good luck with that).
It would also be Really Nifty (tm) if some common utils such as ls and
less output could be included in the sample output, so that one could
play with the colors without endlessly opening/closing the dialogs.
Feel free to suggest an 'apply' button for Console
(http://sourceforge.net/tracker/?group_id=43764&atid=437332). Then you
would just 'ls' (or whatever) at a regular command prompt, and then
'Apply' would update the window for instant results.
I'm not sure for how many years I've been doing this wrong in Windows
shell setup, but it never ever occurred to me that I was changing the
definition of "black" to 255,255,255 and the definition of "white" to
0,0,0 -- rather than just choosing black for my foreground and white
for my background...
Apparently I never noticed as 'Doze doesn't have anything I use in
shell that color-codes anything anyway.
Right; 'doze is not big on color in console programs.
And now I realize that cygwin probably has zero control over this
dialog, and it's entirely Microsoft's fault. That explains a whole
lot.
Yup. But it sounds like you might like Console a lot better. :-)
Or, before Gary tries to convert me again, rxvt will let you do the same
things, although it's more traumatic a switch than Console (note it
isn't installed by default; you need to install it via setup.exe).
I appreciate everybody's input on this, and apologize that it has
turned out to be completely OT, as far as I can tell.
Well, you can always http://cygwin.com/acronyms/#TITTTL :-), although I
still think it's at least somewhat relevant.
--
Matthew
We apologize for the inconvenience.
--
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: Color Schemes
George wrote: On Thu, Aug 31, 2006 at 09:44:51AM -0500, mwoehlke wrote: Dave Korn wrote: AFAIUI, the mapping of escape codes to which visual colours they mean is utterly fixed by ANSI, and it is, as you say, the termulator's job to display the correct visual colour. We could attempt in cygwin's console-handling code to look up the current console's current palette and attempt some kind of best-fit matching, at least in theory, but there's still the old SHTDI problem there [...] and I am not aware of any way to examine the terminal's "palette", nor should you need to. If a user wants to fiddle with these, it is his responsibility to keep things legible. Huh? $ grep color ~/.Xdefaults *color0:#00 *color1:#D1BFB1 *color2:#99 *color3:#C8B27F *color4:#8DB6CD *color5:#CC99CC *color6:#A8A8D9 *color7:#7697A7 *color8:#00 *color9:#80A0B0 *color10: #99 *color11: #40677A *color12: #8DB6CD *color13: #CC99CC *color14: *color15: #87CEFF *colorBD: #8DB6CD *colorUL: #C8B27F *cursorColor: #84A9A9 Or am I missing something? Sure. Now do it for Konsole (hint: DCOP *might* let you), CUI, Console, rxvt, PuTTY, and every other terminal emulator in existence. What you found is the *default* colors for *one* emulator (what happens if you override them with command-line switches?). Dave and I were talking about being able to query the terminal emulator in a standardized way, and I am pretty sure there is no such way. -- Matthew We apologize for the inconvenience. -- 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: Color Schemes
(Still can't decide if I should TITTTL this...) Dave Korn wrote: AFAIUI, the mapping of escape codes to which visual colours they mean is utterly fixed by ANSI, and it is, as you say, the termulator's job to display the correct visual colour. We could attempt in cygwin's console-handling code to look up the current console's current palette and attempt some kind of best-fit matching, at least in theory, but there's still the old SHTDI problem there Eh? It's not fixed in any way. It is entirely up to the terminal emulator to decide what color to display e.g. '1;35' as. The *default* and accepted standard is "magenta", which is '255,0,255' in Windows CUI, something more like '255,96,255' on a 'real IBM terminal' (i.e. an x86 running in real text mode, like back in the day, or like pure console mode on Linux, or like in the BIOS boot, etc). But there is no reason I can't tell my terminal emulator (CUI, Console, rxvt, Konsole, probably xterm) to display it as sea green (say, '64,128,224'). Just as there is no reason I can't tell my terminal emulator that '0;30' should be dark green (which I do with Konsole in one of my schema's). I can even make it transparent and have my wallpaper, or a background image, displayed instead. All the color code is, is a hint to the terminal emulator. ...and I am not aware of any way to examine the terminal's "palette", nor should you need to. If a user wants to fiddle with these, it is his responsibility to keep things legible. -- Matthew We apologize for the inconvenience. -- 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 when using variable assignment, backticks in shell script
CARTER Alan wrote: In any case, it's pretty weird that bash randomly fails to spawn child processes! It wreaks havoc on a number of my scripts. Thought: Silent failure to spawn used to happen on some UNIX boxen when the process table was full (or one slot remained and user != root). Might something like this be causing your problem? (I'm not going to stress my work Windows box this way to attempt to reproduce, it's too unstable already.) Regards, Alan Carter This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. Hmm... 9 lines of content, 10 of disclaimer... *sip!* Eew, and the disclaimer isn't even line-wrapped... (How come PCYMTNILOAUD is not on the OLOCA yet? ;-)) -- Matthew We apologize for the inconvenience. -- 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: Color Schemes
Dave Korn wrote: On 30 August 2006 23:02, mwoehlke wrote: Richard Lynch (Contractor) wrote: Noobie cygwin alert! Hopefully this isn't too verbose... Well, I stopped reading about halfway through... Just a moment too soon, alas. I like color-coding of ls and vim and man and all that. But I can't handle the default color scheme. My eyes are too old. So I changed the colors in cygwin DOS-like shell preferences to black foreground and white background. If you are using the CUI (started your shell from a .bat file or ran bash.exe directly), right-click the title bar, pick 'properties' and go to the 'colors' tab (you might also find the 'font' tab useful; it will let you change the text size). I believe that's exactly what he meant by "dos-like shell preferences". I suspected as much, but hedged my bet. Besides, you never know what newbie is actually /searching the archives/ :-). (Complaint in no way directed at you, Richard). Unfortunately I don't know anything about how to make cygwin aware of these colours. Aware? Cygwin is never aware of them; that's the point. All the terminal knows is '1;32', '0;37', etc. It is the job of the terminal emulator to decide how to present those. That's the whole point of my suggestion to change them at that level, where the underlying programs *don't* know a thing about it. That way they can't break it. :-) It sounds to me like what Richard is currently doing is changing the color code used for the default background (which will cause problems), rather than leaving it alone and changing the presentation of the various color codes. -- Matthew Now where did I put my hippo? -- 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: Color Schemes
Richard Lynch (Contractor) wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Dave Korn Sent: Wed 8/30/2006 5:13 PM To: [EMAIL PROTECTED] Subject: [SPAM] RE: Color Schemes [snip] Eek! Please, PLEASE http://cygwin.com/acronyms/#PCYMTNQREAIYR, especially if it's dropping the list address in here! Also, please consider losing the http://cygwin.com/acronyms/#TOFU; having it below a recognized signature causes Thunderbird to completely strip out the previous quoting. -- Matthew Now where did I put my hippo? -- 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: Color Schemes
Richard Lynch (Contractor) wrote: I'm starting cygwin from the Start menu that cygwin installed, which windows 'properties' show as mapped to: C:\cygwin\cygwin.bat I used the 'Properties' in that window to get the scheme I wanted, and applied to the thingie that launched this shell. I've also modified the 'properties' from the Start menu item directly, and clicked on the pretty color icons instead of typing the digits, as suggested. Um, wait, I suggested doing the exact *opposite*. I thought that maybe you could change the mappings so that things asking for black would get white, vice versa, and so on. However, you have to be careful to re-select the original "pretty color icon" when you are done, or things that don't ask get what you had selected. This leads to things like a '1;37' background with '1;37' text, which, as you noticed, makes for 'invisible ink'. What I think you want to do is tell the CUI that '0;30' should be '255,255,255', '1;37' should be '0,0,0', etc, so that you will have something that is legible in all circumstances (unless something is asking for the same foreground and background, in which case you were screwed even before you started tinkering - but I haven't seen any Cygwin programs with that problem). It "works", even on launching another, in that I can change the color scheme of the bash shell any way I like, but it has no effect I can tell on the ANSI colors of termcap which define 'less' behaviour, nor the LS_COLORS that define 'ls' behaviour. If you change the numbers as I mentioned, then anything asking for e.g. '1;31' will show up as whatever you changed 'bright red' to be. My 'man man' output now looks like this: --- man - format and display the on-line manual pages man [] [ ] [ system] [ string] [ config_file] [ pathlist] [ pager] [ section_list] [section] name ... --- Note that all the things that 'less' would reverse-video are effectively "invisible" This implies that you have somehow set the default background color to '1;37'. Less is then displaying text as '1;37'. I don't think you can change less without hacking it, but I don't think you want to; if you go this route, you'll be chasing down this issue in dozens of programs. Editing /etc/termcap by hand, however, is way beyond my skill level, and I been doing this stuff for a couple decades... I am not sure what you would accomplish by editing termcap; I don't think termcap has any control over this (except maybe you could disable text attributes entirely, but I'm not sure what the point would be... and just setting TERM to something like maybe 'dumb' would take care of that). -- Matthew Now where did I put my hippo? -- 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: Color Schemes
Richard Lynch (Contractor) wrote:
Noobie cygwin alert!
Hopefully this isn't too verbose...
Well, I stopped reading about halfway through...
I like color-coding of ls and vim and man and all that.
But I can't handle the default color scheme. My eyes are too old.
So I changed the colors in cygwin DOS-like shell preferences to black
foreground and white background.
This was great, except that all the built-in Un*x tools such as ls, less,
man, etc are still assuming the original color scheme.
[snip]
It sounds like what you want to do is leave the color codes alone and
change the mapping, which is done in your terminal emulator and will
affect ALL programs (because you are changing how your terminal emulator
presents colors). This will let you make white black, black white, and
so forth; any programs that are still broken when using this method are
just plain broken. Note: you want to EDIT the color values, not just
pick different colors for foreground, background, etc. So if you are
using the CUI, be sure to re-select the right color before hitting 'ok'.
If you are using the CUI (started your shell from a .bat file or ran
bash.exe directly), right-click the title bar, pick 'properties' and go
to the 'colors' tab (you might also find the 'font' tab useful; it will
let you change the text size).
If you are using Marko's excellent Console (which can be obtained from
http://sourceforge.net/projects/console), go to Edit->Settings; colors
are in 'Console' which is active by default, the font is under 'Appearance'.
If you are using rxvt, you will have to use command line switches, which
means you must do some reading; either the manpage ('man rxvt') or find
the shell script I wrote; it is in the thread "Re: copying and pasting
in the terminal window?" in the talk list (which also "discusses" the
benefits and drawbacks of Console vs. rxvt).
--
Matthew
Now where did I put my hippo?
--
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: [Mingw-msys] POSIX names for drive letters
Schwarz, Konrad wrote: Also, someone called Interix a POS, which I can't find on http://cygwin.com/acronyms, but I guess is derogatory (I originally though "POsix Simulation" or something, to tell the truth). Is there a list of reasons of the drawbacks of Interix somewhere? Um, yeah, that would be derogatory. :-) Canonical list? I doubt it, but... - Not open source - Bad support for Windows pipes ...and mainly, trying to do 'make' on a large project consistently caused my shell to hang, with the result that it was Just Plain Unusable. IOW, it was absolutely useless to me, therefore IMO a POS. :-) FYI: http://www.acronymdb.com/acronym/POS <-- yup, derogatory... (alas, google works better when you already know what it stands for ;-)) -- Matthew Now where did I put my hippo? -- 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: Unable to automatically map a drive letter at login
Corinna Vinschen wrote: On Aug 29 16:25, mwoehlke wrote: Ok, because I've noticed that the 32-bit 'net.exe' on 64-bit systems seems to be Just Plain Broken. Sorry that wasn't it... :-) Really? It works for me, at least for the `net use' case... Honest. On my 64-bit computer (2003 R2 x64 - maybe XP is OK?), the 32-bit 'net.exe' did not want to work correctly, but the 64-bit net.exe was/is OK. Ultimately I copied the 64-bit one to somewhere that Windows would not redirect it into nonexistence. -- Matthew Now where did I put my hippo? -- 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: Unable to automatically map a drive letter at login
Grant Miller wrote: On 8/29/06, mwoehlke <[EMAIL PROTECTED]> wrote: Grant Miller wrote: I just rebooted one of the Windows systems and tried to SSH in to a now clean system (nobody else logged in since booting) with ssh keys and a script in my .bash_profile to attach to a drive letter and I got the same error (System error 85 has occurred). I also changed the drive letter the script was trying to map from h: to q: (a random drive letter that I haven't used before) and I still got the same error. Omitting the drive letter and using UNC paths works, but it's not going to be pretty. Are you using a 64-bit Windows by any chance? I'm testing and troubleshooting on Windows Server 2003 (regular 32-bit). My other systems are running Windows XP Pro (32-bit) and XP Pro x64, but we're probably going to dump the 64-bit system and stick with 32-bit systems (for application reasons). Ok, because I've noticed that the 32-bit 'net.exe' on 64-bit systems seems to be Just Plain Broken. Sorry that wasn't it... :-) -- Matthew Ncurses. Blessing console programs since 1993. -- 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: Unable to automatically map a drive letter at login
Grant Miller wrote: I just rebooted one of the Windows systems and tried to SSH in to a now clean system (nobody else logged in since booting) with ssh keys and a script in my .bash_profile to attach to a drive letter and I got the same error (System error 85 has occurred). I also changed the drive letter the script was trying to map from h: to q: (a random drive letter that I haven't used before) and I still got the same error. Omitting the drive letter and using UNC paths works, but it's not going to be pretty. Are you using a 64-bit Windows by any chance? -- Matthew Ncurses. Blessing console programs since 1993. -- 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 message or dialog when a DLL is missing
Shankar Unni wrote: Pierre Baillargeon wrote: Thanks for the information. I will not submit a patch because I suspect the current behavior is prefered by the majority: having a dialog pop-up in the middle of scripts is much more catastrophic is most case than having a return code, for unattended processing. So I expect the patch to be badly received by end users. Perhaps the right thing would be for "somebody" to emit an error (read on). On Linux, etc., when a shared library is missing at runtime, any attempt to execute a binary depending on it will get an error like: % /usr/bin/xvidtime /usr/bin/xvidtune: error while loading shared libraries: libXdmcp.so.6: cannot open shared object file: No such file or directory I'm pretty this message is coming directly from (in this case) ld-linux.so (the "DLL loader" on linux). If Cygwin is intercepting the equivalent exception on Windows, perhaps a possible compromise would be for cygwin1.dll to emit such an error to stderr? That would be my vote as well; failing with return code 128 is far less helpful, and printing to "stderr" (or whatever is eating off that pipe) is much more script-friendly than a GUI pop-up. At any rate, I've seen '128's before. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech -- 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: Why is $DISPLAY wrong?
mwoehlke wrote: Igor Peshansky wrote: On Mon, 28 Aug 2006, mwoehlke wrote: Gary R. Van Sickle wrote: Oh, and... "rxvt: can't open display 127.0.0.1:0" I think you have either installed the wrong one or have DISPLAY set wrong. Of course $DISPLAY is set wrong. /etc/prodile.d/qt3.3.sh sets it unconditionally to 127.0.0.1:0, which also breaks 'ssh -X'. Anyone know *why* it's doing this? 'Cause it's broken? Can it be fixed? (I assume this comes from a qt package ;-) but I don't know who maintains those.) It's not in the official distribution: <http://cygwin.com/packages/qt/>. You'd probably better ask whoever you got it from (but not on this list). It isn't? http://cygwin.com/packages/qt3/ http://cygwin.com/packages/qt3-bin/ http://cygwin.com/packages/qt3-devel/ http://cygwin.com/packages/qt3-doc/ Ah, but on further investigation, I see that it doesn't come from those, it came from qt3-x11, which I don't remember installing. So it isn't a Cygwin package that's to blame, and IIRC none of this is supported any more anyway. :-) -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech -- 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: Why is $DISPLAY wrong?
Igor Peshansky wrote: On Mon, 28 Aug 2006, mwoehlke wrote: Gary R. Van Sickle wrote: Oh, and... "rxvt: can't open display 127.0.0.1:0" I think you have either installed the wrong one or have DISPLAY set wrong. Of course $DISPLAY is set wrong. /etc/prodile.d/qt3.3.sh sets it unconditionally to 127.0.0.1:0, which also breaks 'ssh -X'. Anyone know *why* it's doing this? 'Cause it's broken? Can it be fixed? (I assume this comes from a qt package ;-) but I don't know who maintains those.) It's not in the official distribution: <http://cygwin.com/packages/qt/>. You'd probably better ask whoever you got it from (but not on this list). It isn't? http://cygwin.com/packages/qt3/ http://cygwin.com/packages/qt3-bin/ http://cygwin.com/packages/qt3-devel/ http://cygwin.com/packages/qt3-doc/ '[ -z "$DISPLAY" ] && export DISPLAY=127.0.0.1:0' seems to work better. Nope, it's worse. Perhaps the user left DISPLAY unset for a reason... I don't want simply installing some package to muck up my $DISPLAY... "Better". The other alternative is to simply remove the line, which is probably "best". :-) -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech -- 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/
Why is $DISPLAY wrong? (was: copying and pasting in the terminal window?)
Gary R. Van Sickle wrote: Oh, and... "rxvt: can't open display 127.0.0.1:0" I think you have either installed the wrong one or have DISPLAY set wrong. Of course $DISPLAY is set wrong. /etc/prodile.d/qt3.3.sh sets it unconditionally to 127.0.0.1:0, which also breaks 'ssh -X'. Anyone know *why* it's doing this? Can it be fixed? (I assume this comes from a qt package ;-) but I don't know who maintains those.) '[ -z "$DISPLAY" ] && export DISPLAY=127.0.0.1:0' seems to work better. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech -- 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: POSIX names for drive letters
Schwarz, Konrad wrote: Hi, I know that it is kind of late :-), but I would like to suggest an alternative/additional mapping of drive letters to the MinGW and Cygwin file-system name space. The proposed mapping for directory `C:\' is `//./C$/' (or perhaps `//./C/'). The reasons for this mapping are: [snip] So... why exactly do you need this? The only thing I might actually support here (keeping in mind Eric's comments and CGF's clear agreement with them) would be treating '//./' as a special case of '//127.0.0.1/', at which point '//./C$/' is the UNC mapping of the default 'C$' share on the local machine. But I still fail to see why that is useful. Or you could change your mount prefix to '/dev/fs', and have '/dev/fs/c', etc, which seems more "natural" and is also what Interix uses (so you have compatibility in case you ever use that POS). -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- 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: copying and pasting in the terminal window?
Eric Hanchrow wrote: "mwoehlke" == mwoehlke <[EMAIL PROTECTED]> writes: Please configure your e-mail program to omit this obnoxious header that includes the spam-invitation of quoting raw e-mail addresses (see also PCYMTNQREAIYR). All those '>'s confuse Thunderbird (using some other character would be OK). mwoehlke> Awesome? It appears to be xterm No, it's rxvt. Different program. Ok, it is "an xterm replacement", meaning it is like xterm. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech -- 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: FW: Issue using regtool on a 64-bit Windows host
Christopher Fay wrote: I am writing a PERL script to verify registry entries on a 64-bit Windows R2 system. It appears that when doing the regtool command "regtool list /HKLM/SOFTWARE/..." regtool is actually looking at "/HKLM/Software/Wow6432Node/...". I am unable to get the registry info for /HKLM/SOFTWARE. Does anyone have any ideas for this? Use a 64-bit regtool. Um... which means you have to find a Microsoft version, or build your own that doesn't rely on Cygwin. That, or port gcc to Windows64. :-) You could also investigate if there is a way to get around the 32->64 indirections, but you would have to update regtool to use it. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech -- 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: copying and pasting in the terminal window?
Gary R. Van Sickle wrote: From: mwoehlke Cygwin also has an rxvt terminal emulator that may be more to your liking, but I haven't used it and so can't tell you what it's like. It's awesome, if you're still using the DOS box change over immediately. Believe me now and thank me later. Awesome? It appears to be xterm (which I never liked to begin with), which needs an X server and is a PITA to configure, has an ugly font, and probably has issues running certain CUI applications (at least I know I've heard such rumors). And I see exactly zero ways in which it is an improvement over Console. Console is awesome, if you're still using rxvt change over immediately. Believe me now and thank me later. :-) If you *must* have an X-based terminal emulator for some reason (or even just something that isn't using the CUI subsystem under the covers), I would strongly recommend Konsole as VASTLY superior to xterm/rxvt. You can get an old version... um, somewhere, or wait and see if KDE4 makes good on native Windows support (which I guess would no longer be X-based, but would also not need an X server). -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech -- 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 message or dialog when a DLL is missing
Pierre Baillargeon wrote: Problem: when running a program from bash and the program requires a DLL that is missing (or lacks a particular function), I do not get any error message nor dialog box. Only a exit status of 128. Can I change this behavior? What I expected is a dialog would pop-up saying "XYZ.dll not found" like cmd.exe does, for example. I assume you are running 'on the glass'? Are you using rxvt or some other terminal emulator other than Windows CUI (which you get running 'bash' either directly or via direct invocation of either a .bat or cmd.exe), especially something that is known to cause this like a local putty session? -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- 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: copying and pasting in the terminal window?
Eric Hanchrow wrote: "John" == John Salerno <[EMAIL PROTECTED]> writes: John> Hi everyone. I just installed cygwin on WinXP and I'm John> wondering if there is a way to copy and paste in the command John> prompt, like in Linux? Sure. But it's a feature of cmd.exe, not of Cygwin. In other words, you can do what I'm about to describe on _any_ Windows box. Um... that would be "feature of the CUI subsystem". It has no more to do with cmd.exe than it has to do with bash; both cmd.exe and bash are shells; the CUI is the terminal (emulator). -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- 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: copying and pasting in the terminal window?
John Salerno wrote: Hi everyone. I just installed cygwin on WinXP and I'm wondering if there is a way to copy and paste in the command prompt, like in Linux? I figured the cygwin terminal would look and act more like the bash shell, but so far it doesn't for me. Does this mean I'm still using a DOS prompt? (Despite the $ prompt instead of C:\)? There is a difference between the "shell" and the "terminal emulator". In Windows, all console applications (including Cygwin 'bash') get a "console window". If you right-click on the window title and see 'properties', you probably have a "console window". From here, you probably want to go to 'options' and turn on 'quick edit mode' (remember to 'modify the shortcut that started this window' when prompted). This will let you select as you are used to, but you will have to right-click to 'copy', and right-click again to 'paste'. Not quite Linux, but better than the default behavior. Cygwin also has an rxvt terminal emulator that may be more to your liking, but I haven't used it and so can't tell you what it's like. -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- 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: Usage Of Cron and AT commands
Ugh, http://cygwin.com/acronyms/#TOFU - reformatted (but the .sig looks better, thanks!) Also, PCYMTNQREAIYR (although the cruddy line wrapping just barely saved mine from being quoted raw). [EMAIL PROTECTED] wrote: mwoehlke wrote: [EMAIL PROTECTED] wrote (again): Hi CygWinners, I would like to know the syntax of crontab, cron and at commands for its use in task scheduling. [snip] Please read the replies to your first post instead of posting again. I have read the replies to my previous post and that is the very reason I am rewriting this mail, the previous mailer by Mr. chuck Who is "Mr. Chuck"? had just mentioned using "man crontab", which is not what I want. Please reply to the unhelpful messages, stating how they were unhelpful, instead of re-posting. I am not using crontab and am using cron and at for batch processing crontab = _tab_le of _cron_ jobs. If you are using cron, you are using crontab. I want to know where to add the permissions for allowing cron jobs... The previous mail has not solved my problem.. Did you read the manpages for both 'cron' and 'crontab'? Did you read the documentation Dave told you to read? Also see Larry's reply. -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- 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: coreutils 5.97; mkdir -p; mkdir: cannot create directory `name': File exists
Rolf Campbell wrote: I believe there is a race-condition in "mkdir -p". Specifically, if the directory does not exist *yet* when stat is called on line #98 of "coreutils-5.97/lib/mkdir-p.c", but the directory *does* exist by the time line #190 of the same file calls mkdir(), then the program will error with "File exists". I hit this occasionally when doing parallel builds. The coreutils list would be a nice place to send this, unless you have reason to believe that only Cygwin is affected? -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Looking for mkdirhier !
Dave Korn wrote: On 22 August 2006 16:57, mwoehlke wrote: Dave Korn wrote: On 22 August 2006 07:50, Guillaume MARTIN wrote: How could I install mkdir in cygwin ? [EMAIL PROTECTED] /tmp> alias mkdirhier='mkdir -p' ...but you would have to set that alias in whatever this script is... Better: $ cat > /bin/mkdirhier mkdir -p "$@" ^D $ chmod +x /bin/mkdirhier (Note: ^D above means hold 'ctrl' and press 'D') Would be even better if you put a shebang on the first line, in case it's invoked from a non-bash shell. Actually, I intentionally did not use a shebang... 'mkdir -p "$@"' should work on any Bourne-like shell, although in this case '#!/bin/sh' should suffice. I'm used to writing portable scripts; anything other than '#!/bin/sh' is very non-portable, and if the script needs to be run on Bourne+ (i.e. bash or ksh), then the only options are a: try to write a wrapper that invokes the script in bash/ksh as a here-doc (or something equally ugly), or b: don't use a shebang. I generally pick the latter. -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- 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: Usage Of Cron and AT commands
[EMAIL PROTECTED] wrote (again): Hi CygWinners, I would like to know the syntax of crontab, cron and at commands for its use in task scheduling. [snip] Please read the replies to your first post instead of posting again. And please lose the obnoxiously long signature and unenforceable disclaimer. Everything below your name is superfluous, and quoting your e-mail address is inviting spam (similarly, you should set your 'to' to display your name instead of your e-mail address). -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Looking for mkdirhier !
Dave Korn wrote: On 22 August 2006 07:50, Guillaume MARTIN wrote: How could I install mkdir in cygwin ? [EMAIL PROTECTED] /tmp> alias mkdirhier='mkdir -p' ...but you would have to set that alias in whatever this script is... Better: $ cat > /bin/mkdirhier : mkdir -p "$@" ^D $ chmod +x /bin/mkdirhier (Note: ^D above means hold 'ctrl' and press 'D') -- Matthew '$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys 4d:2h:14m:43.712s -- 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: Send command and parameters into cygwin.bat
mocs wrote: Ive would like to edit my cygwin.bat so a command into "cygwin" starts automatically with a document and some parameters, how should i write? 'man bash' -- Matthew KATE: Awesome Text Editor -- 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: group"S-1-2-0"(users who login locally)in ssh;windows 2003
Tom Rodman wrote: Yes I see the local group "S-1-2-0", but when I ssh'd in, I typed the password in for this session and so I expect "whoami /all" to return the username that goes with the password - more importantly I need the credentials to write to the network shares, that I normally get when using ssh via password authentication. Hmm, what'd I miss? What is it that is needed to write to network shares? (And is it a 2k3 thing?) I have MAJOR problems with my network shares; even though they do not need un/pw to access, I always have to unmount and remount them to be able to write (even on Remote Desktop and 'on the glass' logins, so it isn't (just) a Cygwin thing). Since we got on the subject, anyone know why that is? -- Matthew KATE: Awesome Text Editor -- 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 running from ext. USB HD
Dirk Schleicher wrote: Hello there, it is possible to install cygwin on a external USB-hd? I think yes. I use W2k and want to store my mails from Sylpheed claws there. Or install cygwin normal and store the whole mails at the USB HD. To do this I have to mount the USB HD to cygwin. How to do this? 'man mount' -- Matthew Websites such as ... Wikipedia ... are reputed to occupy users for periods in excess of 5 hours. -- Wikipedia article on Internet Addiction -- 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: change in behavior of make from 3.80 to 3.81
Olivier Langlois wrote: Just for the records: My design goals for Cygwin are that it works fine as a POSIX environment, not that it works fine to run DOS tools. That's a nice side-effect at best. It seems to me that Cygwin design goals have changed recently otherwise if offering a POSIX environment while coexisting nicely with DOS tools was not one of the legacy Cygwin design goal, how comes this feature/behavior has been included for so many years in Cygwin? How about backward compatibility as a design goal? Backward compatibility is a nice design goal, you know. FLOSS is not known for keeping backward compatibility particularly high in their list of design goals. :-) -- Matthew Websites such as ... Wikipedia ... are reputed to occupy users for periods in excess of 5 hours. -- Wikipedia article on Internet Addiction -- 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: Start up Script Question
Rich Mayo wrote: What script (or scripts) adds Cygwin directories to the existing environment variables? I use xterm under the Cygwin X Server as my user environment and I'm not happy with the way my INCLUDE, LIB, and PATH variables are laid out. 'man bash' -- Matthew Websites such as ... Wikipedia ... are reputed to occupy users for periods in excess of 5 hours. -- Wikipedia article on Internet Addiction -- 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: change in behavior of make from 3.80 to 3.81
Igor Peshansky wrote: On Wed, 16 Aug 2006, mwoehlke wrote: Igor Peshansky wrote: Alternatively, you can try to implement a $(cygpath ...) function in make and submit *that* to the upstream maintainers. That way, the Cygwin make will not have to invoke a separate process to convert the paths that it (as a program linked to cygwin1.dll) already knows how to do. I'd like to point out that such a patch would be all of about five lines of "code"... (And for the record, I've written both new make functions AND my own version of cygpath, so I know what I'm talking about.) Properly written, perhaps about 10. But what's a constant factor between friends? ;-) Ah, I was thinking about the version of cygpath I wrote, that only does absolute conversions, and thus is less code. :-) Also see below. Except note you would almost certainly want $(cygpathu) and $(cygpathw). Umm, actually I was thinking of $(cygpath) with 2 parameters -- the type of conversion, and the list of paths. Oh, right. I think I was thinking about it taking a list of files, but that is of course what $(foreach) is for. Your way is more flexible but requires more coding (because then you have to think about how to handle the 'what type of conversion' argument). So it is 10 lines of code instead of 5... and you're still just *copying* the source of cygpath. -- Matthew vIMprove your life! Now on version 7! -- 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: change in behavior of make from 3.80 to 3.81
Igor Peshansky wrote: Alternatively, you can try to implement a $(cygpath ...) function in make and submit *that* to the upstream maintainers. That way, the Cygwin make will not have to invoke a separate process to convert the paths that it (as a program linked to cygwin1.dll) already knows how to do. I'd like to point out that such a patch would be all of about five lines of "code"... (And for the record, I've written both new make functions AND my own version of cygpath, so I know what I'm talking about.) Except note you would almost certainly want $(cygpathu) and $(cygpathw). Because no one seems to have gotten the point yet, http://cygwin.com/acronyms/#SHTDI ...and that somebody is not likely to be one of the people not having problems, so if all these other posters would kindly put their patches where their mouths are, then maybe something would be accomplished. -- Matthew vIMprove your life! Now on version 7! -- 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: group"S-1-2-0"(users who login locally)in ssh;windows 2003
Tom Rodman wrote: Hosts effected: several boxes running windows 2003 server w/cygwin (1.5.20s(0.155/4/2) 20060403 13:33:45) Problem (or feature?): when you ssh to these boxes, and run: $WINDIR/system32/whoami /all |grep -q S-1-2-0 || echo OOPs # "OOPS" echos :-< "S-1-2-0" == "Users who log on to terminals locally (physically) connected to the system." Under windows 2000 (also a different cygwin version), ssh sessions show group membership in "S-1-2-0": $ '/drv/c/Program Files/Resource Kit/whoami' /all|grep S-1-2-0 [Group 9] = "LOCAL" S-1-2-0 The reason I care is that is that several tools we call from cygwin, will not run unless the session is in S-1-2-0. What makes you say this? What tools? I'm not sure if this is a cygwin version issue, or due to windows 2003. Any thoughts/can others test this in an ssh session?: $WINDIR/system32/whoami /all |grep -q S-1-2-0 || echo OOPs FWIW, on my 2k3 box, I show up as a member in S-1-2-0 both logged in "locally" (via Remote Desktop Sharing, with which I have never had anything "not work") and via Cygwin sshd. Under ssh, all privileges are "enabled", under "local", only SeChangeNotifyPrivilege, SeImpersonatePrivilege and SeCreateGlobalPrivilege are enabled. Here are all system group memberships "local" groups: --- Everyone Well-known group S-1-1-0 LOCAL Well-known group S-1-2-0 NT AUTH*\REMOTE INTERACTIVE LOGON Well-known group S-1-5-14 NT AUTH*\INTERACTIVE Well-known group S-1-5-4 NT AUTH*\Authenticated Users Well-known group S-1-5-11 NT AUTH*\This OrganizationWell-known group S-1-5-15 NT AUTH*\NTLM Authentication Well-known group S-1-5-64-10 BUILTIN\AdministratorsAliasS-1-5-32-544 BUILTIN\Users AliasS-1-5-32-545 (*Abbreviated for line-wrapping) ssh groups: --- Everyone Well-known group S-1-1-0 LOCALWell-known group S-1-2-0 NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 NT AUTHORITY\SERVICE Well-known group S-1-5-6 BUILTIN\Administrators AliasS-1-5-32-544 BUILTIN\UsersAliasS-1-5-32-545 This probably doesn't have much to do with your problem, but might relate to some of the other ssh problems people (including myself) have been having. -- Matthew vIMprove your life! Now on version 7! -- 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: change in behavior of make from 3.80 to 3.81
John W. Eaton wrote: On 15-Aug-2006, Joachim Achtzehnter wrote: Clearly, developers make a huge contribution, nobody is denying this, but to suggest that *only* developers contribute and everybody else should therefore just shut up I never said everyone else should "just shut up". My point was that if you aren't contributing in some way, then you shouldn't expect your complaining to carry much weight. The way to get things done is to do the work, not just complain and hope that people do something for you. ...or offer money. That carries more weight than complaining. :-) However that doesn't work in all cases. This I am reasonably confident is one of them. But as a general rule... Obligatory-make-behavior-content: It seems there is really no need for this discussion now, as there are several options available for someone willing to do the work: [snip mingw bullet] * Patch your own version of GNU Make for Cygwin (I don't think that the patch used with the previous version is a secret). Of course it isn't "secret". GNU make is GPL'd, therefore Cygwin's patched version of it was also. Since it was distributed, compliance with the GPL means that source code was also available; further, anyone still offering 3.80-cygwin is required to provide it. -- Matthew Only Joe suffers from schizophrenia. The rest of us enjoy 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: openmotif, .rdata, shared libs and runtime linking/loading problem
Avi Cohen Stuart wrote: [snip] gdb reports the following: Program received signal SIGSEGV, Segmentation fault. [snip] The address it is trying to write to appears to be a read only address in the attempt to resolve some adresses and updating pointers it crashes. I've no idea why openmotif/whatever would be broken, but the above sentence makes me wonder if '-fwritable-strings' (gcc option) would help. If it does, shame on someone for writing bad code. N.B. sorry for the repost. I suspect that a different subject draws more attention... Yes. It draws attention to the fact that you have now (potentially) annoyed us by posting twice. -- Matthew Only Joe suffers from schizophrenia. The rest of us enjoy 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: Permissions problems after domain change
Chuck wrote: Larry Hall (Cygwin) wrote: Chuck wrote: My winXP ID was recently moved from one domain to another. Now when I log in to cygwin, I don't have permissions to access some of my own files - like my ssh id_rsa file for example. Can someone tell me what I need to do to fix this? Also, the group name is showing up as all question marks when I do an "ls -l". Can anyone help me fix this? TIA. $ ls -laF total 64 drwx--+ 17 CHamilto Domain Users 0 Aug 15 10:21 ./ drwx--+ 3 CHamilto Domain Users 0 Apr 6 17:10 ../ -rw--- 1 CHamilto Users 6998 Jul 13 09:50 .bash_history -rw--- 1 CHamilto Domain Users 0 Oct 7 2004 .ICEauthority -rw-r--r-- 1 CHamilto Domain Users 354 Oct 7 2004 .XSM-Default -rw-r--r-- 1 CHamilto Domain Users93 Oct 11 2004 .Xdefaults [snipped] drwx--+ 2 CHamilto 0 Aug 15 12:28 .keychain/ drwx--+ 2 CHamilto 0 Jul 26 09:12 .ssh/ Looks to me like you just need to recreate your '/etc/group' and '/etc/passwd' files. Try: mkpasswd -l -d >/etc/passwd mkgroup -l -d >/etc/group If this takes too long, look at the -D flag for each so you can specify the domain. Doesn't seem like my versions of these commands support the -D option. $ mkpasswd -l -D mkpasswd: unknown option -- D Try 'mkpasswd --help' for more information. $ mkgroup -l -D mkgroup: unknown option -- D Try 'mkgroup --help' for more information. Did you try 'man mkpasswd'? It looks like the correct syntax is 'mkpasswd -l -d [ ...]' -- Matthew Only Joe suffers from schizophrenia. The rest of us enjoy 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: change in behavior of make from 3.80 to 3.81
William A. Hoffman wrote: At 10:40 PM 8/14/2006, Igor Peshansky wrote: - The other option is to use mingw-make, and only use cygwin make for cygwin linked programs only. Incorrect. If you use Cygwin make, it's very easy to invoke Windows programs by converting their arguments with "cygpath -w" (or, barring that, with a perl or sed script). I've done that, others have done that. If you are generating the code to invoke the Microsoft cl compiler, simply use something like $(foreach f,$^,$(shell cygpath -w $f)) as the argument to cl. I have to say yuck!, and performance hit. So, for every path that gets passed to the compiler you have to launch a process that does string allocation and conversion. I do not think this is a realistic solution for larger projects. I would not want CMake to generate makefiles with cygpath -w being invoked multiple times per compiler run. So, I will restate that there is no workable solution to use cl with cygwin make anymore. As one of those "others", I have to point out that it WJFFM. As for "larger projects", I just had to make a source tarball, so I have a nice statistic: *gzip'd*, it's about 2.6 MB. I'd say that qualifies as "large". I guess that makes me not "realistic"? Is it slower? Yeah, but that's part of doing business. Some time I may decide to optimize it by converting some of my wrapper scripts to C code. I think the hit is from the "launch a process" step, not "string allocation and conversion". Also, you could translate paths to e.g. '$DRIVEC/some/where.c', and use $(subst) to alternately replace '$DRIVEC' (which should be a unique identifier, like '__this_is_drive_c', NOT '/cygdrive/c') with a POSIX or DOS equivalent as appropriate. -- Matthew Only Joe suffers from schizophrenia. The rest of us enjoy 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: change in behavior of make from 3.80 to 3.81
William A. Hoffman wrote: At 04:16 PM 8/14/2006, Christopher Faylor wrote: I'm not 100% clear on what you're saying but if cmake distributed with Cygwin is producing makefiles with MS-DOS SYNTAX then, actually it should either be fixed to not do that or it should be pulled from the distribution. I wasn't aware of this limitation. The cmake distributed with cygwin produces cygwin makefiles and only cygwin makefiles. It is unaffected by the change in make from 3.80 to 3.81. There is no such limitation, please don't remove cmake from cygwin. Since that cmake links to the cygwin runtime it know about /cydrive/c and uses it. The change affects the microsoft build of cmake. That build is available on a separate download from www.cmake.org. It has an option to generate "Unix Makefiles". In the past, you could use this mode to create Makefiles that would drive Microsoft's cl with a cygwin make. This no longer works. I am trying to figure out if there is change I can make to the windows build of cmake, that will cause it to generate makefiles that will work with both make 3.80, and 3.81 from cygwin. Before this is carried much further... does it work with the mingw 'make'? -- Matthew "We're all mad here. I'm mad. You're mad... You must be, or you wouldn't have come here." -- The Cheshire Cat -- 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: Rsync over ssh (pulling from Cygwin to Linux) stalls..
Darryl Miles wrote: I do have questions, they may seem daft, but this issue is legal thing so the finer points are important: [snip] I'd be happy to put the bugfixes for this particular problem in the public domain, thus confirming my original legal entitlement to copyright and waivering that right. Which would may waiver anyone elses future rights to copyright as well. This would seem a compatible solution which would allow contributions without needing to enter into a copyright assignment agreement. Since my name wont be listed anywhere on the published work (since as I read the agreement it would be replaced by RedHats anyway) I might as well make the contribution public domain. IANALTYMSIEIAATS... My understanding is that if you place it in Public Domain, then anyone can do anything with it and no one can stop this. IOW RedHat would be safe because no one can prevent them from using Public Domain material in any manner or fashion. Similarly, you have the same right; no one can prevent *you* from doing anything at all with your work. The main issue, of course, is that you lose any and all ability to control the use of your work. It sounds to me like what you want to do is release a GPL version of your work. Again, my understanding is that this makes it 'still your work' in that you can do anything you want with it, and also anyone else can use it in any way that the GPL allows. I believe GPL release is non-revokable, meaning you can't later change your mind (if not, I'm sure GPL would have died by now), so this should protect anyone who uses your work in compliance with GPL. But it sounds like this is inadequate? (I haven't actually looked at RedHat's assignment form, so...) Corrina, it would seem RedHat has an interest in this conversation... are your lawyers available for comment? :-) I would think you could at least make an internal inquiry if they would be willing to talk to Daryl. -- Matthew "We're all mad here. I'm mad. You're mad... You must be, or you wouldn't have come here." -- The Cheshire Cat -- 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: Um... what format are Cygwin manpages?
Joshua Daniel Franklin wrote: On 8/10/06, mwoehlke wrote: Joshua Daniel Franklin wrote: > Yes, it's sort-of my fault. I just have a Perl script that chunks the > newlib libc.info files into faux man pages. Ah, ok, makes sense. Too bad newlib doesn't have proper manpages, in that case. Although am I understanding that newlib itself doesn't have *any* manpages, meaning a: I need to be fixing their INFO, and b: any manpages should be sent this way after all? Well, I'd be for fixing the newlib files rather than replacing them. The issue with replacing them with our own custom versions or with Linux ones is that the documentation no longer comes from the actual upstream libc (or worse-- in the case of Linux it comes from a possibly incompatible *different* upstream libc). ...which is why we're not replacing it with the Linux one. :-) I took the Linux one and *edited* it until it seemed to match the actual observed-and-tested behavior of Cygwin's newlib. Along the way I discovered that newlib is not C99-conformant (see earlier posts). Anyway, if it turns out I have to patch an info file, then I guess I'm stuck doing that. Assuming anyone on newlib pays attention to me. So far, zilch. If you'd like to add better *roff formatting to the perl script, it's in the cygwin-doc src package. A warning, though, it's a mess. Heh, maybe I'll take a crack, but that's something a lot more complicated... there is really not a good LaTeX->roff convertor out there? (Or maybe newlib has just-as-poorly-formatted LaTeX... ;-)) -- Matthew vIMprove your life! Now on version 7! -- 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: Um... what format are Cygwin manpages?
Joshua Daniel Franklin wrote: On 8/9/06, mwoehlke wrote: I thought I'd have a crack at fixing the manpage for printf(3) (see http://cygwin.com/ml/cygwin/2006-08/msg00288.html), but when I opened it, I was a bit shocked to discover that it is only *MARGINALLY* in troff format. I do note that other manpages seem more "normal" (man1 pages, for instance)... So, is this just "how the C lib manpages are"? Yes, it's sort-of my fault. I just have a Perl script that chunks the newlib libc.info files into faux man pages. Ah, ok, makes sense. Too bad newlib doesn't have proper manpages, in that case. Although am I understanding that newlib itself doesn't have *any* manpages, meaning a: I need to be fixing their INFO, and b: any manpages should be sent this way after all? (Btw, symlinks for sprintf, fprintf, snprintf, etc, seem to be missing?) Anyway, if you're maintaining info->man, I totally understand why that would have the format it does. I would be more confused if someone was actually maintaining not-nroff nroff. :-) Be careful with Linux man pages, some are licensed from the Open Group. If so the package should come with a copyright file like this: http://packages.debian.org/changelogs/pool/non-free/m/manpages-posix/manpages-posix_1.67-3/manpages-posix.copyright Unfortunately we are not allowed to redistribute those, unless you'd like to do the legwork to get permission to do so. :) .\" Copyright (c) 1999 Andries Brouwer ([EMAIL PROTECTED]) .\" .\" This is free documentation; you can redistribute it and/or .\" modify it under the terms of the GNU General Public License as .\" published by the Free Software Foundation; either version 2 of .\" the License, or (at your option) any later version. I assume the above is OK? :-) Also I just posted for upload a new cygwin-doc package before I read this thread, so there would be more of a delay. Bummer. Oh, well. -- Matthew vIMprove your life! Now on version 7! -- 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: Ansi escape sequences showing in Man pages
No http://cygwin.com/acronyms/#TOFU please, and http://cygwin.com/acronyms/#PCYMTNQREAIYR... thanks! [EMAIL PROTECTED] wrote: Igor Peshansky wrote: On Wed, 9 Aug 2006, jbonnett wrote: I am having a problem where escape sequences, rather than colour highlighting, appear when I display man pages. [snip] Any clues about what to check to fix this on my work machine? Unset PAGER. Unset PAGER did not fix things, but after reading some man pages on the Internet, I discovered a way to make things work for me. PAGER="less -r" Export PAGER After that I get readable highlighted man pages. Hmm, you shouldn't have to do that. What is the output of the following commands (with PAGER and MANPAGER unset)? $ unset PAGER ; unset MANPAGER # no output, but do this first $ man -d man 2>&1 | tail -n 1 # what man thinks it is doing $ grep PAGER /usr/share/misc/man.conf # what man is being told to use (note: '#' and things after are comments; you don't need to type them) You should get something like: $ unset PAGER ; unset MANPAGER $ man -d man (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/cat '/usr/share/man/man1/man.1') | /usr/bin/tbl | /usr/bin/nroff -c -mandoc 2>/dev/null | /usr/bin/less -isrR) $ grep PAGER /usr/share/misc/man.conf PAGER/usr/bin/less -isrR ...mostly you are looking for sane arguments (-r in particular) being given to 'less'. If not, you may need to edit /usr/share/man.conf, although I would be curious to know how your man.conf got to having a bad PAGER (if that turns out to be the problem). -- Matthew This is not the list you're looking for. -- Perversion of Obi Wan -- 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: Um... what format are Cygwin manpages?
Larry Hall (Cygwin) wrote: mwoehlke wrote: Christopher Faylor wrote: On Wed, Aug 09, 2006 at 01:10:11PM -0500, mwoehlke wrote: I have a modified Linux manpage almost ready to go; I assume that goes to cygwin.patches? No, that would be appropriate only if the man page was found in the winsup hierarchy. The first line of printf(3) says "NEWLIB" when I type "man 3 printf" so that's where a man page patch should go. Ok, that's what I kind-of thought... Hmm, shame on the newlib folks for having such a poorly-up-to-date manpage. :-) Anyway, I guess this means that gmane.comp.lib.newlib will suffice? If that equates to newlib at sources dot redhat dot com, then yes. http://gmane.org/list-address.php?group=gmane.comp.lib.newlib Seems to... (But... this means what? If the newlib folks don't like it, Cygwin is just stuck with a /wrong/ manpage?) Well, we could scold them mercilessly and send them to their rooms without dinner. ;-) Let's not look for a problem that doesn't currently exist. Well then, let's hope they accept it. And in a timely manner, would be nice. :-) Ok, so the other question... assuming it is accepted upstream tomorrow, how long would it likely take to find its way into a Cygwin package? -- Matthew This is not the list you're looking for. -- Perversion of Obi Wan -- 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: Cygintl-3.dll was not found
infoterror wrote: Under windows, programs are installed by default in "C:\Program Files." cygwin's preferred "c:\cygwin" is foolish and makes an unnecessary mess of installations. Cygwin's "c:\cygwin" contains AN ENTIRE (virtual) FILESYSTEM. I don't know about you, but *I* sure don't want that sort of thing under "Program Files" (besides which, POSIX-ish systems don't really appreciate spaces in file/path names). Here's some food for thought: the default installation path for SFU is "%WINDIR%\SUA", and that is because it is a Windows component. Before it was a Windows component, it was "C:\SFU". Do you really think Microsoft did this because they were "following Cygwin's lead"? Or maybe they had a more compelling/logical reason for violating /their/ policy in this instance? I would be surprised if defaulting to "C:\Program Files\Cygwin") didn't cause any problems. -- Matthew This is not the list you're looking for. -- Perversion of Obi Wan -- 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: Um... what format are Cygwin manpages?
Christopher Faylor wrote: On Wed, Aug 09, 2006 at 01:10:11PM -0500, mwoehlke wrote: I have a modified Linux manpage almost ready to go; I assume that goes to cygwin.patches? No, that would be appropriate only if the man page was found in the winsup hierarchy. The first line of printf(3) says "NEWLIB" when I type "man 3 printf" so that's where a man page patch should go. Ok, that's what I kind-of thought... Hmm, shame on the newlib folks for having such a poorly-up-to-date manpage. :-) Anyway, I guess this means that gmane.comp.lib.newlib will suffice? (But... this means what? If the newlib folks don't like it, Cygwin is just stuck with a /wrong/ manpage?) -- Matthew This is not the list you're looking for. -- Perversion of Obi Wan -- 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: Um... what format are Cygwin manpages?
mwoehlke wrote:
mwoehlke wrote:
I thought I'd have a crack at fixing the manpage for printf(3) (see
http://cygwin.com/ml/cygwin/2006-08/msg00288.html), but when I opened
it, I was a bit shocked to discover that it is only *MARGINALLY* in
troff format. I do note that other manpages seem more "normal" (man1
pages, for instance)... So, is this just "how the C lib manpages are"?
I am not going to submit a "patch" on this mess. If I do anything with
it, I am going to submit a proper troff document. Given how much work
I would have to do to fix the existing page, I am much more inclined
to take my printf.3 from my Linux box and adjust it into consistency
with Cygwin's printf() instead. I'm willing to clean up the existing
manpage, but I think the style of the Linux manpage would be an
improvement (what we have looks like it came from HP-UX or something).
Any opinions?
Ok, no doubt this manpage needs to be overhauled. I am going from the
Linux page and finding several omissions in the one currently in Cygwin
("%F", as well as "%ll?").
WCTS, does anyone know to what extent locale stuff is supported? The
"%'" modifier? "%*d", etc? "%$1d", etc? "%*1$d", etc?
Ok, experimenting shows that all of the above EXCEPT "%'" are supported
(no great surprise). However, I also noticed that "%a", which is
required by C99, is not supported?
I have a modified Linux manpage almost ready to go; I assume that goes
to cygwin.patches?
--
Matthew
This is not the list you're looking for. -- Perversion of Obi Wan
--
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/
