Re: No xauth program
On 01/09/2010 20:29, Scott T. Marshall wrote: when I connect using ssh -Yv localhost the last few lines of output are: debug1: Entering interactive session. debug1: No xauth program. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing. Last login: Wed Sep 1 15:03:40 2010 from ::1 I don't understand the No xauth program part. I have xauth in /bin which xauth returns /usr/bin/xauth and when I check the permissions on xauth, I see that they are 755 and I am the owner. You might like to try if xauth can actually run successfully? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: No xauth program
Thanks for the suggestion Jon. I don't know exactly what I should ask xauth to do or what syntax is requires (the man page was not completely clear to me), but what I can say is that if I try to execute xauth in an xterm, it gives no errors. I can also say that when I ssh to other linux machines, I can open X applications, but my cygwin/windows 7 x64 box will not forward x windows when someone log onto it. -Scott On 9/2/2010 11:11 AM, Jon TURNEY wrote: On 01/09/2010 20:29, Scott T. Marshall wrote: when I connect using ssh -Yv localhost the last few lines of output are: debug1: Entering interactive session. debug1: No xauth program. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing. Last login: Wed Sep 1 15:03:40 2010 from ::1 I don't understand the No xauth program part. I have xauth in /bin which xauth returns /usr/bin/xauth and when I check the permissions on xauth, I see that they are 755 and I am the owner. You might like to try if xauth can actually run successfully? -- Scott T. Marshall Department Of Geology Appalachian State University 572 Rivers St. Boone, NC 28608 http://www.appstate.edu/~marshallst/ ftp://pm.appstate.edu/pub/prog/marshallst/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: No xauth program
On 9/2/2010 11:11 AM, Jon TURNEY wrote: On 01/09/2010 20:29, Scott T. Marshall wrote: when I connect using ssh -Yv localhost the last few lines of output are: debug1: Entering interactive session. debug1: No xauth program. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing. Last login: Wed Sep 1 15:03:40 2010 from ::1 I don't understand the No xauth program part. I have xauth in /bin which xauth returns /usr/bin/xauth and when I check the permissions on xauth, I see that they are 755 and I am the owner. You might like to try if xauth can actually run successfully? On 02/09/2010 18:56, Scott T. Marshall wrote: Thanks for the suggestion Jon. I don't know exactly what I should ask xauth to do or what syntax is requires (the man page was not completely clear to me), but what I can say is that if I try to execute xauth in an xterm, it gives no errors. I can also say that when I ssh to other linux machines, I can open X applications, but my cygwin/windows 7 x64 box will not forward x windows when someone log onto it. Hmm... it looks like the latest openssh package has the wrong default path to xauth for some reason. As a workaround, you might try adding XAuthLocation=/usr/bin/xauth to /etc/sshd_config and restarting sshd. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 1.7.[67]: getting bash prompt takes 50 seconds
Am 02.09.2010, 04:30 Uhr, schrieb Mark Callow: Hi Andrey, Did you tried to *uninstall* bash-completion? I have now. Surprisingly (to me) it worked. The time-to-prompt has dropped to ~5 seconds on one of the machines and ~8 seconds on the other. Both are still too long but a vast improvement over 50 seconds. You can open a cmd.exe terminal window and type bash --login -x (or -xv) to figure if it spends a particularly long time in a certain area of the .bashrc execution, however, Cygwin is indeed a lot slower than Unix when shell scripting, because creating Unix processes is very costly in Cygwin, and that is an operation that happens a lot in shell scripts... -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: chere not working with zsh version 4.3.10 but worked for 4.3.9
Hi Reckoner, Does not work is insufficient information about your problem. How did it work before? What happens now? Did you get an error message? If yes, what was it? You should follow the procedure described in: Problem reports: http://cygwin.com/problems.html Also, you may want to read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
simulating console input
Hello, I would like to run a Dos program, that needs keyboard input (just one Y), automatically via make in an ssh-session. How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... The keypress is accepted only in a dos-console. TIA for any help! Peter -- Contact information: http://pmrb.free.fr/contact/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: difference running from cmd vs. bash?
On Thu, Sep 2, 2010 at 2:14 AM, Linda Walsh wrote: In Bash: winmgmt /verifyrepository WMI repository verification failed Error code: 0x8007007E That is the COM error code for The specified module could not be found. Perhaps bash has altered the PATH. Do you get the same error when running winmgmt without any parameters? If yes, here's how to find out which DLL is not found: cugcheck 'c:\Windows\System32\Wbem\winmgmt.exe' This will give you a list of which DLLs are loaded and which ones are missing. -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simulating console input
Greetings, Peter Munster! I would like to run a Dos program, that needs keyboard input (just one Y), automatically via make in an ssh-session. How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... The keypress is accepted only in a dos-console. If the program reading keyboard directly, you can't do it through IO redirection. Look for alternatives or write a replacement, that don't block execution. -- WBR, Andrey Repin (anrdae...@freemail.ru) 02.09.2010, 15:06 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: can't compile setup.exe
On 02/09/2010 06:42, Andy Koppe wrote:
On 2 September 2010 05:18, Vasya Pupkin wrote:
I'm trying to compile setup.exe from source code I got from CVS.
Great!
For some reason, I am getting an error:
propsheet.cc: In member function `bool PropSheet::SetActivePage(int)':
propsheet.cc:444: error: expected id-expression before '::' token
propsheet.cc:444: error: expected `)' before '::' token
propsheet.cc:444: error: expected `;' before '::' token
propsheet.cc:444: error: expected `;' before ')' token
propsheet.cc: In member function `bool PropSheet::SetActivePageByID(int)':
propsheet.cc:452: error: expected id-expression before '::' token
propsheet.cc:452: error: expected `)' before '::' token
propsheet.cc:452: error: expected `;' before '::' token
propsheet.cc:452: error: expected `;' before ')' token
propsheet.cc: In member function `void PropSheet::SetButtons(DWORD)':
propsheet.cc:459: error: expected id-expression before '::' token
propsheet.cc:459: error: expected `;' before '::' token
propsheet.cc: In member function `void PropSheet::PressButton(int)':
propsheet.cc:465: error: expected id-expression before '::' token
propsheet.cc:465: error: expected `;' before '::' token
make[2]: *** [propsheet.o] Error 1
I did not touch this file. I installed all required packages and
followed instruction in README file.
Hmm, newly fails for me too, and I can't work out why, given that the
line in question is ancient code. I configured thusly:
./configure -C --disable-shared --host=i686-pc-mingw32
--build=i686-pc-cygwin CC=gcc-3 -mno-cygwin CXX=g++-3 -mno-cygwin
This was broken by the recent w32api-3.15 update, which seems to have made
those PropSheet macros C++ aware, so the global scoping operator is no longer
needed.
Patch attached to fix it, but I couldn't work out how to also get it to build
with w32api-3.14.
Index: propsheet.cc
===
RCS file: /cvs/cygwin-apps/setup/propsheet.cc,v
retrieving revision 2.15
diff -u -r2.15 propsheet.cc
--- propsheet.cc30 Jun 2009 04:14:29 - 2.15
+++ propsheet.cc29 Aug 2010 09:51:13 -
@@ -441,7 +441,7 @@
PropSheet::SetActivePage (int i)
{
// Posts a message to the message queue, so this won't block
- return static_cast bool (::PropSheet_SetCurSel (GetHWND (), NULL, i));
+ return static_cast bool (PropSheet_SetCurSel (GetHWND (), NULL, i));
}
bool
@@ -449,18 +449,18 @@
{
// Posts a message to the message queue, so this won't block
return static_cast bool
-(::PropSheet_SetCurSelByID (GetHWND (), resource_id));
+(PropSheet_SetCurSelByID (GetHWND (), resource_id));
}
void
PropSheet::SetButtons (DWORD flags)
{
// Posts a message to the message queue, so this won't block
- ::PropSheet_SetWizButtons (GetHWND (), flags);
+ PropSheet_SetWizButtons (GetHWND (), flags);
}
void
PropSheet::PressButton (int button)
{
- ::PropSheet_PressButton (GetHWND (), button);
+ PropSheet_PressButton (GetHWND (), button);
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simulating console input
On 2010-09-02 9:47 AM, Peter Münster wrote: Hello, I would like to run a Dos program, that needs keyboard input (just one Y), automatically via make in an ssh-session. How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... The keypress is accepted only in a dos-console. TIA for any help! Peter Does echo Y | DosProgram.exe work in a cmd window? If so it should be possible to do something like (untested) cmd /c echo Y | pgm -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: can't compile setup.exe
On 2 September 2010 09:38, Jon TURNEY wrote: This was broken by the recent w32api-3.15 update, which seems to have made those PropSheet macros C++ aware, so the global scoping operator is no longer needed. Patch attached to fix it, but I couldn't work out how to also get it to build with w32api-3.14. #if (__W32API_MAJOR_VERSION == 3 __W32API_MINOR_VERSION 15) should do the trick. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: scp and cygwin randomly and automatically converts text files from utf-8 to windows encoding (cp1251)
I found the reason - it is the combination Far2 and plug-in Call Command. I use this plugin for run commands to synchronize the current list of editable files to the server with ssh, it is clear that both rsync and scp to copy files already modified encoding. While running from command plug-in Call Command current edited file from utf-8 automatically converted (and stored on disk) in encoding cp1251, and to complete the re-encoded back. Perhaps this feature of the implementation of unicode in Far2, but it was very difficult to expect such behavior from these applications. Sorry, that turned up the wrong. Thanks. Andy Koppe wrote: On 31 August 2010 20:23, rPman wrote: It happens when files are copied from cygwin windows machines to any linux (tried different versions of ubuntu and gentoo with utf-8 locale). Cygwin does not change the encoding of file content when copying files. Cygwin 1.7 does translate file names between the UTF-16 encoding used by Windows and the encoding you have configured in Cygwin via the LC_ALL, LC_CTYPE or LANG variables. Please try to desribe in more detail what you were trying to do and how it went wrong. Also, what version of Cygwin are you using? As it is not possible to understand in what cases are re-encoding, sometimes enough to add one blank line in a text file that, when the transfer encoding has not happened. Just changing the format of a newline (in the source files are unix-style \n, but on the linux machine has come to win-style \r\n) Line endings are a separate issue from character encodings. By default, directories are mounted in binary mode, where file content is left alone. Alternatively, they can be mounted in text mode, were line endings are automatically translated between Windows and Unix style. See http://www.cygwin.com/cygwin-ug-net/using-textbinary.html for lots more on that. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/scp-and-cygwin-randomly-and-automatically-converts-text-files-from-utf-8-to-windows-encoding-%28cp1251%29-tp29586716p29604628.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: can't compile setup.exe
On 09/02/2010 07:38 AM, Jon TURNEY wrote: This was broken by the recent w32api-3.15 update, which seems to have made those PropSheet macros C++ aware, so the global scoping operator is no longer needed. Patch attached to fix it, but I couldn't work out how to also get it to build with w32api-3.14. Would an appropriate set of 'using' directives help? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 12:49 AM, Vasya Pupkin wrote: No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: I read Andy's comment to mean that the mess of your own making is the result of you changing the permissions, not the existing permissions as left by setup.exe. You made the mess (or correction as you see it) and are now fighting with setup.exe to maintain it. drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This + sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. The + indicates that there are further permissions specified as ACLs for which the getfacl and setfacl commands should be used to view and manipulate, respectively. You would see the same behavior from ls on a Linux system which had ACL support and extra ACLs applied to a similar file or directory. There, too, chmod would not be able to modify those ACLs. What your example does not indicate is that anything unintentional happened with the application of permissions on that example directory. Nor does it indicate that the given permissions are in any way harmful to the maintenance of your system or the use of the files and directories in question. Where was that directory located? Did you create it, or did setup.exe create it? What problems do those permissions cause? Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. I'm sure the Cygwin developers would be more than willing to patch any defect surrounding the incorrect application of permissions to files which is the result of Cygwin itself or setup.exe. Unfortunately, you have not demonstrated any such erroneous behavior yet. It seems more likely that you have a small misunderstanding about how the permissions you see work and how they are represented under Cygwin. Have you read the section of the user guide which discusses permissions under Cygwin? Perhaps, you have found a genuine defect. If so, you need to provide more data so that someone else can reproduce the problem. You could start by installing another instance of Cygwin into a fresh directory (this won't affect your primary installation) and then demonstrate the specific files that have faulty permissions and explain how those permissions will lead to further problems. With luck, someone will be able to explain why things are the way you see them such that you are comfortable accepting how Cygwin does things. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
If you read again very carefully, you will see that I modified permissions AFTER I noticed they were messed up. Ok? In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. I was asked why I care about permissions, so I answered. Anyway, the problem is solved now, I also submitted an easy patch to setup.exe source for everyone who want to get rid of this problem as well. If I ever get into a problem with permissions again, I will try to make a proper bug report instead of just fixing permissions. On Thu, Sep 2, 2010 at 6:28 PM, Jeremy Bopp jer...@bopp.net wrote: On 9/2/2010 12:49 AM, Vasya Pupkin wrote: No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: I read Andy's comment to mean that the mess of your own making is the result of you changing the permissions, not the existing permissions as left by setup.exe. You made the mess (or correction as you see it) and are now fighting with setup.exe to maintain it. drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This + sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. The + indicates that there are further permissions specified as ACLs for which the getfacl and setfacl commands should be used to view and manipulate, respectively. You would see the same behavior from ls on a Linux system which had ACL support and extra ACLs applied to a similar file or directory. There, too, chmod would not be able to modify those ACLs. What your example does not indicate is that anything unintentional happened with the application of permissions on that example directory. Nor does it indicate that the given permissions are in any way harmful to the maintenance of your system or the use of the files and directories in question. Where was that directory located? Did you create it, or did setup.exe create it? What problems do those permissions cause? Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. I'm sure the Cygwin developers would be more than willing to patch any defect surrounding the incorrect application of permissions to files which is the result of Cygwin itself or setup.exe. Unfortunately, you have not demonstrated any such erroneous behavior yet. It seems more likely that you have a small misunderstanding about how the permissions you see work and how they are represented under Cygwin. Have you read the section of the user guide which discusses permissions under Cygwin? Perhaps, you have found a genuine defect. If so, you need to provide more data so that someone else can reproduce the problem. You could start by installing another instance of Cygwin into a fresh directory (this won't affect your primary installation) and then demonstrate the specific files that have faulty permissions and explain how those permissions will lead to further problems. With luck, someone will be able to explain why things are the way you see them such that you are comfortable accepting how Cygwin does things. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simulating console input
On 9/2/2010 3:47 AM, Peter Münster wrote: Hello, I would like to run a Dos program, that needs keyboard input (just one Y), automatically via make in an ssh-session. How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... The keypress is accepted only in a dos-console. Read http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console. Then add this fact - the SSH server uses ptys. So your program will not work with a single character put in the input buffer. One could envision using 'yes' to fill the buffer of the pipe that the Windows program interprets the pty to be. Perhaps a nicer alternative is to build the problematic program with Cygwin, if that's an option, so that it will understand the pty. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 10:05 AM, Vasya Pupkin wrote: If you read again very carefully, you will see that I modified permissions AFTER I noticed they were messed up. Ok? I tried to point out that your definition of messed up is the opposite of Andy's. To you, the default permissions provided by setup.exe are messed up. To Andy, the permissions you created are messed up. I hope that clarifies things. In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. Yes, the more I read, the more I come to believe that the disconnect here is in the definition of correct and acceptable permissions. Your definition differs from that of the Cygwin developers. It's good that your permissions changes worked for you, but it's possible that they won't work for everyone. A better description of your original problem as well as how your proposed solution addresses that problem would allow for a more productive discussion. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. I was asked why I care about permissions, so I answered. Anyway, the problem is solved now, I also submitted an easy patch to setup.exe source for everyone who want to get rid of this problem as well. If I ever get into a problem with permissions again, I will try to make a proper bug report instead of just fixing permissions. Your answer was simply an assertion that there possibly was and may still be something wrong with the permissions handling under Cygwin, but that you also haven't confirmed that recently. The details really would be helpful and likely necessary if you would like to have your patch accepted by the maintainers of setup.exe. The only other option is to independently maintain your patch and rebuild your version of setup.exe any time the upstream version changes. This won't help most users, though, because they will either not know about your patch or not care to build their own setup.exe without having any evidence of an existing problem and assurance that your change doesn't introduce other problems. If you're satisfied with your solution, so be it, but you could pretty quickly gather the necessary details for a bug report by performing a second installation of Cygwin into a new directory and reporting the flawed permissions. That could lead to the acceptance of your patch or something similar to the benefit of everyone. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Thu, Sep 2, 2010 at 8:25 PM, Jeremy Bopp jer...@bopp.net wrote: Your answer was simply an assertion that there possibly was and may still be something wrong with the permissions handling under Cygwin, but that you also haven't confirmed that recently. The details really would be helpful and likely necessary if you would like to have your patch accepted by the maintainers of setup.exe. No, my patch can't be accepted as it removes permissions handling completely. It wasn't me who started the thread and I believe, my patch can be of interest for anyone else who will search for a solution for this specific problem. Anyway, I don't see how an option to switch off permissions handling by setup.exe can harm while there is similar functionality in cygwin itself. My very limited understanding of C is not enough to do this, and I never worked with GUI applications. But I will see if it can be done via command line switch and if I succeed, I will submit a proper patch. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Windows-style pathname does not work as command - why?
I don't quite understand this behavior: $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe C:\tools\emacs-23.2\bin\runemacs.exe $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found In particular, why is it that bash does not understand that Windows pathname when it is used as a command argument, even though bash and Cygwin clearly understand it when it is used as a command argument? Is that behavior a bug (e.g., does bash try to judge whether the command is an absolute vs. relative pathname without either first converting to a Unix-style pathname or otherwise recognizing Windows-style pathname)? Or is it some known irregularity (resulting from trying to handle both Windows- and Unix-style pathnames) that couldn't be resolved? Thanks, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows-style pathname does not work as command - why?
On 09/02/2010 11:45 AM, Daniel Barclay wrote: I don't quite understand this behavior: $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe C:\tools\emacs-23.2\bin\runemacs.exe $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found In particular, why is it that bash does not understand that Windows pathname when it is used as a command argument, even though bash and Cygwin clearly understand it when it is used as a command argument? Is that behavior a bug (e.g., does bash try to judge whether the command is an absolute vs. relative pathname without either first converting to a Unix-style pathname or otherwise recognizing Windows-style pathname)? You're not the first to notice this, but it's also not the highest priority on my list to look into, because we already recommend using POSIX style paths in the first place. Or is it some known irregularity (resulting from trying to handle both Windows- and Unix-style pathnames) that couldn't be resolved? Oh, I'm sure that bash could be patched to be smarter about DOS-style pathnames. But no one has been bothered by it enough to write a patch yet. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
re: Windows-style pathname does not work as command - why?
I suggest for your convenience, you try making a symbolic link ... Perhaps something like ... $ ln -s /cygdrive/c/tools/emacs-23.2/bin/runemacs.exe /usr/local/bin/runemacs Then open up a fresh shell and see if 'runemacs' now works for you. (the shell you made the symbolic link in, will likely NOT be able to use the new link) new-shell$ runemacs When I tried something similar to your situation, but with VIM I got the following -- $ C:\\PROGRA~1\\vim\\vim72\\gvim.exe cygwin warning: MS-DOS style path detected: /usr/local/bin/C:\PROGRA~1\vim\vim72\gvim.exe Preferred POSIX equivalent is: /usr/local/bin/C:/PROGRA~1/vim/vim72/gvim.exe CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames bash: C:\PROGRA~1\vim\vim72\gvim.exe: command not found - While it may not be easy to make bash properly handle dos style paths for executeables, I do believe that you can make your life much easier with well chosen symbolic links. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
How to get a script file to use bash and ssh
I want to create script files that are not bound to my user id. I want to
create over 20 different scripts files, one for each server I manage. I
have uploaded keys to each server. So all I should have to is enter is the
ssh command
I have put in a file called MyOpenUp.bat the following...
ssh {myserve...@myserverhostname}
I have put that command in a file called MyOpenUp.init
I have created a MyOpenUp.bat file with the following
@echo off
C:
chdir C:\cygwin\bin
bash --init-file MyOpenUp.init -i -l
While the shell opens up all I get is
cygwi...@localhostname ~
$
I am a cygwin newbie. I am sure it is me not understanding the man page
correctly. What am I doing wrong? The Documentation did not help either.
TIA
--
View this message in context:
http://old.nabble.com/How-to-get-a-script-file-to-use-bash-and-ssh-tp29608117p29608117.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to get a script file to use bash and ssh
On 9/2/2010 2:10 PM, PaulHR wrote:
I want to create script files that are not bound to my user id. I want to
create over 20 different scripts files, one for each server I manage. I
have uploaded keys to each server. So all I should have to is enter is the
ssh command
I have put in a file called MyOpenUp.bat the following...
ssh {myserve...@myserverhostname}
I have put that command in a file called MyOpenUp.init
I have created a MyOpenUp.bat file with the following
@echo off
C:
chdir C:\cygwin\bin
bash --init-file MyOpenUp.init -i -l
While the shell opens up all I get is
cygwi...@localhostname ~
$
It looks like you are trying to effectively create one shortcut per
remote host which you can run and automatically have it open an ssh
session to that host using a particular user specific to that host. Is
that a correct assessment?
-Jeremy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
.exe magic in Cygwin
Hello, I would like to estimate theexpenses to port general linux sources to Cygwin. I did look into Cygwins patch for coreutils. It has 1231 lines of diff code. A lot of the stuff is related to the .exe magic done by cygwin. Do I have to implement that magic in this extend into every package that I would like to run on Cygwin or is this rather special in the case of coreutils? Thank you for advice Al -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to get a script file to use bash and ssh
Yes, that is correct.
Jeremy Bopp-3 wrote:
On 9/2/2010 2:10 PM, PaulHR wrote:
I want to create script files that are not bound to my user id. I want
to
create over 20 different scripts files, one for each server I manage. I
have uploaded keys to each server. So all I should have to is enter is
the
ssh command
I have put in a file called MyOpenUp.bat the following...
ssh {myserve...@myserverhostname}
I have put that command in a file called MyOpenUp.init
I have created a MyOpenUp.bat file with the following
@echo off
C:
chdir C:\cygwin\bin
bash --init-file MyOpenUp.init -i -l
While the shell opens up all I get is
cygwi...@localhostname ~
$
It looks like you are trying to effectively create one shortcut per
remote host which you can run and automatically have it open an ssh
session to that host using a particular user specific to that host. Is
that a correct assessment?
-Jeremy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
View this message in context:
http://old.nabble.com/How-to-get-a-script-file-to-use-bash-and-ssh-tp29608117p29608244.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to get a script file to use bash and ssh
On 9/2/2010 2:10 PM, PaulHR wrote:
I want to create script files that are not bound to my user id. I want to
create over 20 different scripts files, one for each server I manage. I
have uploaded keys to each server. So all I should have to is enter is the
ssh command
I have put in a file called MyOpenUp.bat the following...
ssh {myserve...@myserverhostname}
I have put that command in a file called MyOpenUp.init
I have created a MyOpenUp.bat file with the following
@echo off
C:
chdir C:\cygwin\bin
bash --init-file MyOpenUp.init -i -l
That's all more complicated than it needs to be. Just make windows
shortcuts to c:\cygwin\bin\ssh.exe, where Start in: is set to
c:\cygwin\bin, and modify Target: to contain C:\cygwin\bin\ssh.exe
usern...@hostname (without the quotes of course).
Better yet, install mintty if you don't already have it, and set the
shortcuts' target to: C:\cygwin\bin\mintty.exe -e /bin/ssh
usern...@hostname
(Mintty is a much better term window than cmd.)
-heath
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .exe magic in Cygwin
On 09/02/2010 01:25 PM, Al wrote: Hello, I would like to estimate theexpenses to port general linux sources to Cygwin. I did look into Cygwins patch for coreutils. It has 1231 lines of diff code. A lot of the stuff is related to the .exe magic done by cygwin. Do I have to implement that magic in this extend into every package that I would like to run on Cygwin or is this rather special in the case of coreutils? Coreutils tends to be an exception, because it is so core to the system. Other tools that I also maintain, like m4 or findutils, port with 0 patches. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to get a script file to use bash and ssh
On 9/2/2010 2:36 PM, Heath Kehoe wrote: On 9/2/2010 2:10 PM, PaulHR wrote: That's all more complicated than it needs to be. Just make windows shortcuts to c:\cygwin\bin\ssh.exe, where Start in: is set to c:\cygwin\bin, and modify Target: to contain C:\cygwin\bin\ssh.exe usern...@hostname (without the quotes of course). Better yet, install mintty if you don't already have it, and set the shortcuts' target to: C:\cygwin\bin\mintty.exe -e /bin/ssh usern...@hostname (Mintty is a much better term window than cmd.) I was going to suggest much the same things to start; however, there could be issues with home directory settings (necessary for locating the private ssh keys). It might also be good to eventually work in the ssh agent so that the need for passwords can be reduced. BTW, if you only need Cygwin for connecting to remote hosts with SSH, you might find Putty to be a better fit for your needs. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .exe magic in Cygwin
Coreutils tends to be an exception, because it is so core to the system. Other tools that I also maintain, like m4 or findutils, port with 0 patches. Thank you. That gives me back some optimism. I first compiled coreutils without the cygwin patch. It did compile but afterwards the compilation of findutils, etc. was broken. For example configure.status of wget was truncated at the top and out of order at the bottom. That stopped all further efforts of mine. Now I applied that big patch. copy.c complaints an error of an undefined reference ot 'cygwin_spelling'. Guess that is a library I have to install. But some optimism is back Al -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .exe magic in Cygwin
On 09/02/2010 02:06 PM, Al wrote: I first compiled coreutils without the cygwin patch. It did compile but afterwards the compilation of findutils, etc. was broken. For example configure.status of wget was truncated at the top and out of order at the bottom. That stopped all further efforts of mine. Now I applied that big patch. How? The only supported way of building coreutils for cygwin is by using setup.exe to download the sources and several prerequisite tools (cygport, autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'. Other ways work, but I won't support them on this list. See also /usr/share/doc/Cygwin/coreutils.README. copy.c complaints an error of an undefined reference ot 'cygwin_spelling'. Guess that is a library I have to install. Sounds like you didn't run autoreconf (which would have been done automatically via the supported mechanism). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to get a script file to use bash and ssh
On 2 September 2010 20:52, Jeremy Bopp wrote: That's all more complicated than it needs to be. Just make windows shortcuts to c:\cygwin\bin\ssh.exe, where Start in: is set to c:\cygwin\bin, and modify Target: to contain C:\cygwin\bin\ssh.exe usern...@hostname (without the quotes of course). Better yet, install mintty if you don't already have it, and set the shortcuts' target to: C:\cygwin\bin\mintty.exe -e /bin/ssh usern...@hostname (Mintty is a much better term window than cmd.) I was going to suggest much the same things to start; however, there could be issues with home directory settings (necessary for locating the private ssh keys). It might also be good to eventually work in the ssh agent so that the need for passwords can be reduced. That shouldn't be an issue, because HOME, if not set already, is set automatically based on the user's /etc/passwd entry or the Windows HOMEDRIVE and HOMEPATH variables when the initial Cygwin process is started. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to get a script file to use bash and ssh
On 9/2/2010 3:31 PM, Andy Koppe wrote: On 2 September 2010 20:52, Jeremy Bopp wrote: That's all more complicated than it needs to be. Just make windows shortcuts to c:\cygwin\bin\ssh.exe, where Start in: is set to c:\cygwin\bin, and modify Target: to contain C:\cygwin\bin\ssh.exe usern...@hostname (without the quotes of course). Better yet, install mintty if you don't already have it, and set the shortcuts' target to: C:\cygwin\bin\mintty.exe -e /bin/ssh usern...@hostname (Mintty is a much better term window than cmd.) I was going to suggest much the same things to start; however, there could be issues with home directory settings (necessary for locating the private ssh keys). It might also be good to eventually work in the ssh agent so that the need for passwords can be reduced. That shouldn't be an issue, because HOME, if not set already, is set automatically based on the user's /etc/passwd entry or the Windows HOMEDRIVE and HOMEPATH variables when the initial Cygwin process is started. Assuming, of course, that the necessary entry in /etc/passwd is set correctly. The OP sounds pretty green and may have a different idea of his home directory's location than Cygwin deduces, so a little extra hand holding may be in order. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .exe magic in Cygwin
Sounds like you didn't run autoreconf (which would have been done automatically via the supported mechanism). Right. I applied it the traditional way. setup.exe to download the sources and several prerequisite tools (cygport, autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'. Other ways work, but I won't support them on this list. See also As a want to come a hybrid of Cygwin and Gentoos Emerge installer, I rather have to figure out one of those hidden ways. If I can't find it, I have to fall back from Cygwin to Interix. But that would cut half of my target group. /usr/share/doc/Cygwin/coreutils.README. Yes, it's time to dig a little deeper into the Cygwin scripts. It has to be scriptable in the end. Then I can get it into Emerge. A graphical setup.exe is the wrong way for my approach. However there are scripts below. Al -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2 September 2010 16:05, Vasya Pupkin wrote: In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. Intended or not, this is a bug report, and a rather serious one at that. Any further details might be useful. When was it that you saw that problem? Still during the beta phase or after 1.7.1 was released? How did you find the problematic permissions? By looking at the security tab of the file properties? Did you confirm that users really were able to modify files they weren't supposed to? Could the offending privileges have been inherited from the directory Cygwin was installed in? Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 4:49 PM, Andy Koppe wrote: How did you find the problematic permissions? By looking at the security tab of the file properties? Remember that the security tab has the very bad habit of re-ordering the ACLs -- but the effect of ACLs is order dependent. Hence, just looking at the permissions of a cygwin-managed directory or file, using the security tab, can introduce a Heisenbug: there was no bug until you observed the permissions. Use getfacl/setfacl to manipulate the permissions/ACLs of cygwin-managed files. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Fri, Sep 3, 2010 at 12:49 AM, Andy Koppe andy.ko...@gmail.com wrote: How did you find the problematic permissions? By looking at the security tab of the file properties? Did you confirm that users really were able to modify files they weren't supposed to? Could the offending privileges have been inherited from the directory Cygwin was installed in? If only I could remember all the details. I didn't have much time to figure out what happened. Easy solution for me was to disable acl in cygwin, which I did, and was happy until I used setup.exe and found out it destroyed my permissions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simulating console input
On 9/2/2010 3:47 AM, Peter Münster wrote: Hello, I would like to run a Dos program, that needs keyboard input (just one Y), automatically via make in an ssh-session. How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... The keypress is accepted only in a dos-console. Read http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console. Then add this fact - the SSH server uses ptys. So your program will not work with a single character put in the input buffer. One could envision using 'yes' to fill the buffer of the pipe that the Windows program interprets the pty to be. Perhaps a nicer alternative is to build the problematic program with Cygwin, if that's an option, so that it will understand the pty. Would an inline document work? DosProgram.exe ! Y ! - Phil Phil Rising, Principal Consultant for Sogeti USA, LLC Contracted to Nationwide, Corporate Internet and Contact Center Solutions Team (Work) (614) 677-7445, (Fax) (614) 677-7046 Alternate email: phil.ris...@us.sogeti.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows-style pathname does not work as command - why?
On Thu, Sep 02, 2010 at 12:13:12PM -0600, Eric Blake wrote: On 09/02/2010 11:45 AM, Daniel Barclay wrote: I don't quite understand this behavior: $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe C:\tools\emacs-23.2\bin\runemacs.exe $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found In particular, why is it that bash does not understand that Windows pathname when it is used as a command argument, even though bash and Cygwin clearly understand it when it is used as a command argument? Is that behavior a bug (e.g., does bash try to judge whether the command is an absolute vs. relative pathname without either first converting to a Unix-style pathname or otherwise recognizing Windows-style pathname)? You're not the first to notice this, but it's also not the highest priority on my list to look into, because we already recommend using POSIX style paths in the first place. Or is it some known irregularity (resulting from trying to handle both Windows- and Unix-style pathnames) that couldn't be resolved? Oh, I'm sure that bash could be patched to be smarter about DOS-style pathnames. But no one has been bothered by it enough to write a patch yet. And, trying hard to make MS-DOS stuff work is sorta counter to the whole reason for Cygwin. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simulating console input
On 09/02/2010 03:17 PM, risin...@nationwide.com wrote: How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... Would an inline document work? DosProgram.exe! Y ! No. Bash uses a pipe under the hood for here-docs, so it is no different than the already-established non-working 'echo Y | program'. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .exe magic in Cygwin
On 9/2/2010 3:44 PM, Al wrote: setup.exe to download the sources and several prerequisite tools (cygport, autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'. Other ways work, but I won't support them on this list. See also As a want to come a hybrid of Cygwin and Gentoos Emerge installer, I rather have to figure out one of those hidden ways. If I can't find it, I have to fall back from Cygwin to Interix. But that would cut half of my target group. Cygport is rather similar to emerge/ebuild already. You might find it worthwhile to give it a look. /usr/share/doc/Cygwin/coreutils.README. Yes, it's time to dig a little deeper into the Cygwin scripts. It has to be scriptable in the end. Then I can get it into Emerge. A graphical setup.exe is the wrong way for my approach. However there are scripts below. If all you need is a way to install existing Cygwin packages from the command line, you can do that quite well with setup.exe. It has many command line options which help automate the installation process. If you want to build a replacement anyway, you should probably delve into why nothing like what you want exists already. This issue comes up repeatedly on this list, so you should be able to find much in the list archives. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Inability to delete *or rename* CWD of any program driving me nuts
I keep bumping into Cygwin's new inability rename or delete directories that are the CWD of any program. In particular, Emacs will often start background processes like aspell in whatever directory happens to be the default-directory for the current buffer. That program hangs around even after I kill all buffers visiting files in that directory, so even hours after I last edit a file in a directory, I find myself wondering why on earth 'mv' on it hangs. Also, I have (bad?) habit of leaving old terminal windows around, sometimes sitting in directories I later delete or rename. I get rid of them eventually, but having to hunt down and kill them to perform basic filesystem operations is a nuisance. Of course, these annoyances can be worked around, but it was less cumbersome to just allow cwd to be modified. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
export DISPLAY={localWorkstationIP} in mintty
Is there anyway to get the IP address from the local workstation, running
mintty, and putting the local workstation IP address into the export DISPLAY
command running on a different mintty shell, running on a server e.g.
export DISPLAY={localWorkstationIP}
Or, is there a way to get the local workstation IP address in a mintty
shell, to a remote server, in such a fashion that it can be used in the
export command like above?
I am trying to get my xWindows export setup automatically when I sign on.
--
View this message in context:
http://old.nabble.com/export-DISPLAY%3D%7BlocalWorkstationIP%7D-in-mintty-tp29609361p29609361.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: export DISPLAY={localWorkstationIP} in mintty
On 9/2/2010 4:34 PM, PaulHR wrote:
Is there anyway to get the IP address from the local workstation, running
mintty, and putting the local workstation IP address into the export DISPLAY
command running on a different mintty shell, running on a server e.g.
export DISPLAY={localWorkstationIP}
Or, is there a way to get the local workstation IP address in a mintty
shell, to a remote server, in such a fashion that it can be used in the
export command like above?
I am trying to get my xWindows export setup automatically when I sign on.
If you're still connecting to the remote systems with SSH, you can allow
SSH to tunnel the X connection for you using the -X option to the ssh
client you use to make your connection. The remote DISPLAY variable
then automatically points to something which does effectively what you need.
-Jeremy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
setup.exe version 2.721 crashes when performing a reinstall
When I try to use reinstall the setup.exe crashes on Windows XP as well as on Windows 7. The report below is from a crash on Windows 7. Has someone else experienced the same problem? TIA KJ Version=1 EventType=APPCRASH EventTime=129279109701574905 ReportType=2 Consent=1 ReportIdentifier=9038edba-b69d-11df-80fc-0023ae583e0a IntegratorReportIdentifier=9038edb9-b69d-11df-80fc-0023ae583e0a WOW64=1 Response.type=4 Sig[0].Name=Anwendungsname Sig[0].Value=setup.exe_unknown Sig[1].Name=Anwendungsversion Sig[1].Value=0.0.0.0 Sig[2].Name=Anwendungszeitstempel Sig[2].Value=4c77e78c Sig[3].Name=Fehlermodulname Sig[3].Value=StackHash_0a9e Sig[4].Name=Fehlermodulversion Sig[4].Value=0.0.0.0 Sig[5].Name=Fehlermodulzeitstempel Sig[5].Value= Sig[6].Name=Ausnahmecode Sig[6].Value=c005 Sig[7].Name=Ausnahmeoffset Sig[7].Value=ff7e5263 DynamicSig[1].Name=Betriebsystemversion DynamicSig[1].Value=6.1.7600.2.0.0.256.4 DynamicSig[2].Name=Gebietsschema-ID DynamicSig[2].Value=1031 DynamicSig[22].Name=Zusatzinformation 1 DynamicSig[22].Value=0a9e DynamicSig[23].Name=Zusatzinformation 2 DynamicSig[23].Value=0a9e372d3b4ad19135b953a78882e789 DynamicSig[24].Name=Zusatzinformation 3 DynamicSig[24].Value=0a9e DynamicSig[25].Name=Zusatzinformation 4 DynamicSig[25].Value=0a9e372d3b4ad19135b953a78882e789 UI[2]=E:\Downloads\CygInstall\setup.exe UI[3]=setup.exe funktioniert nicht mehr UI[4]=Windows kann online nach einer Lösung für das Problem suchen. UI[5]=Online nach einer Lösung suchen und das Programm schließen UI[6]=Später online nach einer Lösung suchen und das Programm schließen UI[7]=Programm schließen LoadedModule[0]=E:\Downloads\CygInstall\setup.exe LoadedModule[1]=C:\Windows\SysWOW64\ntdll.dll LoadedModule[2]=C:\Windows\syswow64\kernel32.dll LoadedModule[3]=C:\Windows\syswow64\KERNELBASE.dll LoadedModule[4]=C:\Windows\syswow64\ADVAPI32.DLL LoadedModule[5]=C:\Windows\syswow64\msvcrt.dll LoadedModule[6]=C:\Windows\SysWOW64\sechost.dll LoadedModule[7]=C:\Windows\syswow64\RPCRT4.dll LoadedModule[8]=C:\Windows\syswow64\SspiCli.dll LoadedModule[9]=C:\Windows\syswow64\CRYPTBASE.dll LoadedModule[10]=C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.DLL LoadedModule[11]=C:\Windows\syswow64\GDI32.dll LoadedModule[12]=C:\Windows\syswow64\USER32.dll LoadedModule[13]=C:\Windows\syswow64\LPK.dll LoadedModule[14]=C:\Windows\syswow64\USP10.dll LoadedModule[15]=C:\Windows\syswow64\SHLWAPI.dll LoadedModule[16]=C:\Windows\syswow64\OLE32.dll LoadedModule[17]=C:\Windows\syswow64\SHELL32.DLL LoadedModule[18]=C:\Windows\system32\WSOCK32.DLL LoadedModule[19]=C:\Windows\syswow64\WS2_32.dll LoadedModule[20]=C:\Windows\syswow64\NSI.dll LoadedModule[21]=C:\Windows\system32\apphelp.dll LoadedModule[22]=C:\Windows\AppPatch\AcGenral.DLL LoadedModule[23]=C:\Windows\system32\UxTheme.dll LoadedModule[24]=C:\Windows\system32\WINMM.dll LoadedModule[25]=C:\Windows\system32\samcli.dll LoadedModule[26]=C:\Windows\syswow64\OLEAUT32.dll LoadedModule[27]=C:\Windows\system32\MSACM32.dll LoadedModule[28]=C:\Windows\system32\VERSION.dll LoadedModule[29]=C:\Windows\system32\sfc.dll LoadedModule[30]=C:\Windows\system32\sfc_os.DLL LoadedModule[31]=C:\Windows\system32\USERENV.dll LoadedModule[32]=C:\Windows\system32\profapi.dll LoadedModule[33]=C:\Windows\system32\dwmapi.dll LoadedModule[34]=C:\Windows\syswow64\SETUPAPI.dll LoadedModule[35]=C:\Windows\syswow64\CFGMGR32.dll LoadedModule[36]=C:\Windows\syswow64\DEVOBJ.dll LoadedModule[37]=C:\Windows\syswow64\urlmon.dll LoadedModule[38]=C:\Windows\syswow64\CRYPT32.dll LoadedModule[39]=C:\Windows\syswow64\MSASN1.dll LoadedModule[40]=C:\Windows\syswow64\iertutil.dll LoadedModule[41]=C:\Windows\system32\MPR.dll LoadedModule[42]=C:\Windows\system32\IMM32.DLL LoadedModule[43]=C:\Windows\syswow64\MSCTF.dll LoadedModule[44]=C:\Windows\syswow64\CLBCatQ.DLL LoadedModule[45]=C:\Windows\syswow64\wininet.dll LoadedModule[46]=C:\Windows\syswow64\Normaliz.dll LoadedModule[47]=C:\Windows\system32\dnsapi.DLL LoadedModule[48]=C:\Windows\system32\iphlpapi.DLL LoadedModule[49]=C:\Windows\system32\WINNSI.DLL LoadedModule[50]=C:\Windows\system32\RASAPI32.dll LoadedModule[51]=C:\Windows\system32\rasman.dll LoadedModule[52]=C:\Windows\system32\rtutils.dll LoadedModule[53]=C:\Windows\system32\sensapi.dll LoadedModule[54]=C:\Windows\system32\peerdist.dll LoadedModule[55]=C:\Windows\system32\AUTHZ.dll LoadedModule[56]=C:\Windows\system32\NLAapi.dll LoadedModule[57]=C:\Windows\System32\mswsock.dll LoadedModule[58]=C:\Windows\System32\winrnr.dll LoadedModule[59]=C:\Windows\system32\napinsp.dll LoadedModule[60]=C:\Windows\system32\pnrpnsp.dll LoadedModule[61]=C:\Windows\System32\wshtcpip.dll LoadedModule[62]=C:\Windows\System32\wship6.dll LoadedModule[63]=C:\Windows\system32\rasadhlp.dll LoadedModule[64]=C:\Windows\System32\fwpuclnt.dll LoadedModule[65]=C:\Windows\system32\jsproxy.dll LoadedModule[66]=C:\Windows\SysWOW64\jscript.dll
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
There we go, a proper patch. It adds two command line parameters: -f --no-acl-files -F --no-acl-dirs I could not figure if that's possible to share single variable between two source files, so I just used two variables. At least it works as intended and covers every situation. On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. Well, go ahead then. What are you waiting for? Send us a patch. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple filemanip.cc.diff Description: Binary data mkdir.cc.diff Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: export DISPLAY={localWorkstationIP} in mintty
I got the standard error. Error: Can't open display: I made sure xWin Server was running Did a -vvv on the ssh and saw nothing for X11 What else can I look at? -- View this message in context: http://old.nabble.com/export-DISPLAY%3D%7BlocalWorkstationIP%7D-in-mintty-tp29609361p29609623.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
How does one change the default shell?
I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. Is there a way to change the default shell for cygwin? I checked the user guide and the FAQ, but no joy there. I tried setting and exporting the SHELL variable, but that did not work. Thanks, - Phil Phil Rising, Principal Consultant for Sogeti USA, LLC Contracted to Nationwide, Corporate Internet and Contact Center Solutions Team (Work) (614) 677-7445, (Fax) (614) 677-7046 Alternate email: phil.ris...@us.sogeti.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
On 09/02/2010 04:29 PM, risin...@nationwide.com wrote: I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. Is there a way to change the default shell for cygwin? I checked the user guide and the FAQ, but no joy there. I tried setting and exporting the SHELL variable, but that did not work. Assuming you meant the default shell for your particular user id, it is just a matter of changing cygwin.bat or whatever shortcut you are using to start cygwin to call pdksh instead of bash. You can also edit /etc/passwd to set your preferred shell (some tools, like mintty, honor that setting). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
On 09/02/2010 04:29 PM, risin...@nationwide.com wrote: I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. By the way, please don't commandeer threads. Start a new thread for a new topic. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: export DISPLAY={localWorkstationIP} in mintty
On 9/2/2010 5:12 PM, PaulHR wrote: I got the standard error. Error: Can't open display: I made sure xWin Server was running Did a -vvv on the ssh and saw nothing for X11 What else can I look at? It would be really helpful if you included a little context from earlier bits of the conversation to which you are responding. I'm going to assume that you responded to my message suggesting you use the -X option to ssh. ;-) It's possible that the corresponding server-side option to allow that feature is disabled. If so, you could try to reconfigure the ssh server. The option to enable is named X11Forwarding and it should be set to yes. If you are not allowed to do that, then your only option is to go back to your original idea of figuring out your local IP. This will require a bit more effort on your part. When you connect to the remote machine, there should be an environment variable named SSH_CLIENT set. It appears to be a space delimited list where the first item is your client's IP address. Given that and assuming your shell is bash on the server, you can use the following to set the DISPLAY environment variable after you open your connection: export DISPLAY=$(echo $SSH_CLIENT | cut -d' ' -f1):0 If that works for you, you may want to put it in your .bashrc or .bash_profile script on the server side so that it happens automatically every time you connect. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: OpenSSH-5.6p1-1
On 23/08/2010 16:15, Corinna Vinschen wrote: I've just updated the Cygwin version of OpenSSH to 5.6p1-1. This is a new major upstream release. The Cygwin release is created from the vanilla sources. It looks like this update has reverted the default XAuthLocation from /usr/bin/xauth to /usr/X11R6/bin/xauth. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
On 09/02/2010 04:29 PM, risin...@nationwide.com wrote: I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. Is there a way to change the default shell for cygwin? I checked the user guide and the FAQ, but no joy there. I tried setting and exporting the SHELL variable, but that did not work. Assuming you meant the default shell for your particular user id, it is just a matter of changing cygwin.bat or whatever shortcut you are using to start cygwin to call pdksh instead of bash. You can also edit /etc/passwd to set your preferred shell (some tools, like mintty, honor that setting). My /etc/passwd entry: RISINGP1:unused_by_nt/2000/xp:287838:10545:RISINGP1,U-NWIE\RISINGP1,S-1-5-21-725345543-616249376-1177238915-277838:/cygdrive/c/cygwin/home/risingp1:/bin/pdksh My cygwin.bat: @echo off C: chdir C:\cygwin\bin REM bash --login -i REM pdksh -l -i start mintty -p 70,0 -t Console -e - This starts me off in pdksh, but when I execute a shell script, it runs under bash. Any other ideas? Thanks, - Phil P.S. I did not realize I was commandeering the thread. My apologies - it won't happen again. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
On 09/02/2010 04:49 PM, risin...@nationwide.com wrote:
write a script, I have to remember to put in the shebang line
(#!/bin/pdksh) or half the time my scripts won't work.
Is there a way to change the default shell for cygwin? I checked the
user
guide and the FAQ, but no joy there. I tried setting and exporting the
SHELL variable, but that did not work.
Assuming you meant the default shell for your particular user id, it is
just a matter of changing cygwin.bat or whatever shortcut you are using
to start cygwin to call pdksh instead of bash. You can also edit
/etc/passwd to set your preferred shell (some tools, like mintty, honor
that setting).
This starts me off in pdksh, but when I execute a shell script, it runs
under bash.
Ah, so you mean how to change /bin/sh to be pdksh instead of bash. Simple:
cp /bin/{pdk,}sh
But be prepared to redo that every time you upgrade bash via setup.exe,
and don't come crying to the list if things break that were expecting
bash when they got pdksh.
I did not realize I was commandeering the thread. My apologies - it won't
happen again.
Merely changing a Subject: line does not change the In-Reply-To: headers
that form threading.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
[ACK! I just realized I was continuing my usurping of the thread. Sorry.] On 09/02/2010 04:29 PM, risin...@nationwide.com wrote: I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. Is there a way to change the default shell for cygwin? I checked the user guide and the FAQ, but no joy there. I tried setting and exporting the SHELL variable, but that did not work. Assuming you meant the default shell for your particular user id, it is just a matter of changing cygwin.bat or whatever shortcut you are using to start cygwin to call pdksh instead of bash. You can also edit /etc/passwd to set your preferred shell (some tools, like mintty, honor that setting). My /etc/passwd entry: RISINGP1:unused_by_nt/2000/xp:287838:10545:RISINGP1,U-NWIE\RISINGP1,S-1-5-21-725345543-616249376-1177238915-277838:/cygdrive/c/cygwin/home/risingp1:/bin/pdksh My cygwin.bat: @echo off C: chdir C:\cygwin\bin REM bash --login -i REM pdksh -l -i start mintty -p 70,0 -t Console -e - This starts me off in pdksh, but when I execute a shell script, it runs under bash. Any other ideas? Thanks, - Phil P.S. I did not realize I was commandeering the thread. My apologies - it won't happen again. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
Ah, so you mean how to change /bin/sh to be pdksh instead of bash.
Simple:
cp /bin/{pdk,}sh
But be prepared to redo that every time you upgrade bash via
setup.exe,
and don't come crying to the list if things break that were expecting
bash when they got pdksh.
Thanks. I was hoping to effect the change environmentally - not
have to change exe's.
Should I follow that route, no crying will ensue.
I will probably just continue using the shebang line for safety.
- Phil
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The un-notified update of gcc4-4.3.4-3 cause setup failed(build date 2009-12-11 to 2010-08-15, caused file size mismatch)
On 02/09/2010 05:32, LiuYan 刘研 wrote: Today I try to setup cygwin on a new server, it keeps failed with a cyggcc_s-1.dll is missed error in the last post-install phase. I'm sorry it caused you a problem, I'm afraid setup.exe was smarter than I am and it spotted the difference when I hoped it wouldn't. I thought that it would be ok, since cyggcc_s-1.dll would already be installed, so it shouldn't have been looking to upgrade anything. Are you perhaps sharing a local package cache dir between both these machines, on a network shared drive or similar? I rename gcc4 directory to gcc4-old, reinstall gcc4 and libgcc1 package, it works ok finally. Right, that workaround should suffice. I wanted to avoid everyone who already had the package installed from having to redownload it because the only thing that changed was a couple of 'x' permission bits on a couple of the scripts. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .exe magic in Cygwin
On 02/09/2010 21:44, Al wrote: Sounds like you didn't run autoreconf (which would have been done automatically via the supported mechanism). Right. I applied it the traditional way. Ah, you have to understand this about cygport patches: they only contain patches for the source files, not the autogenerated ones. So they have patches for e.g. Makefile.am, configure.ac; but not for configure or even Makefile.in. It's vitally necessary to autoreconf after applying a patch that you get from a cygport-based package. As a want to come a hybrid of Cygwin and Gentoos Emerge installer, I rather have to figure out one of those hidden ways. Well, if you're doing it in a POSIX-compatible environment, you should be able to run cygport - with maybe a few minor bugs cropping up, but basically it's just a bunch of shell scripts that invoke the autotools, gcc and binutils, so they should be relatively easy to port to any similar environment. I did once try running cygport on a linux box (with a cross-compiler). I don't remember exactly what went wrong, it didn't work directly out of the box, but it shouldn't be hard to fix. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Aug 12 01:11, Corinna Vinschen wrote: On Aug 12 06:54, Andy Koppe wrote: On 11 August 2010 20:55, John Carey wrote: So is your idea that if SetCurrentDirectory() fails because of path length or permissions, then Cygwin would just accept the failure and keep an internal record the POSIX current working directory and use that for all Cygwin calls, not the Win32 notion of current directory? Yes. The question then becomes what to do about the Win32 working directory in that case. Actually, Cygwin accepts *any* directory it can open as CWD: - Directories which can only be opened under SE_BACKUP_NAME. - Directories with a length up to 32768 chars. - Virtual directories, which don't exist at all as filesystem-based paths, like /proc, /cygdrive, etc. In Aug 17 10:15, Corinna Vinschen wrote: I just released 1.7.6-1. ... What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api Thank you very much for the fix! I've been running tests against Cygwin 1.7.6, and then 1.7.7, and those sporadic, non-deterministic failures in CreatePipe did stop after the 1.7.6 upgrade, and are still gone in 1.7.7. I think it's been long enough to conclude that it is not just the non-determinism--it really is fixed, as expected. I understand that this issue opened a can of worms; thanks again for your efforts to overcome those difficulties. -- John -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .exe magic in Cygwin
On 9/2/2010 7:46 PM, Dave Korn wrote: I did once try running cygport on a linux box (with a cross-compiler). I don't remember exactly what went wrong, it didn't work directly out of the box, but it shouldn't be hard to fix. It's only the most recent release of cygport (0.10.0) that has rudimentary support for usage on other build environments: 0.10.0: * Added support for building and using cross-compilers. * Experimental support for running cygport on non-Cygwin hosts. IIUC, cygport at best can now be used in the following build vs host situations: cygwin - cygwin other - cygwin cygwin - other I've only tried (1) and (3), not (2). -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: export DISPLAY={localWorkstationIP} in mintty
On 09/02/2010 03:37 PM, Jeremy Bopp wrote: On 9/2/2010 5:12 PM, PaulHR wrote: I got the standard error. Error: Can't open display: I made sure xWin Server was running Did a -vvv on the ssh and saw nothing for X11 What else can I look at? It would be really helpful if you included a little context from earlier bits of the conversation to which you are responding. I'm going to assume that you responded to my message suggesting you use the -X option to ssh. ;-) It's possible that the corresponding server-side option to allow that feature is disabled. If so, you could try to reconfigure the ssh server. The option to enable is named X11Forwarding and it should be set to yes. If you are not allowed to do that, then your only option is to go back to your original idea of figuring out your local IP. This will require a bit more effort on your part. When you connect to the remote machine, there should be an environment variable named SSH_CLIENT set. It appears to be a space delimited list where the first item is your client's IP address. Given that and assuming your shell is bash on the server, you can use the following to set the DISPLAY environment variable after you open your connection: export DISPLAY=$(echo $SSH_CLIENT | cut -d' ' -f1):0 If that works for you, you may want to put it in your .bashrc or .bash_profile script on the server side so that it happens automatically every time you connect. -Jeremy It's been my experience that if you do not have DISPLAY set before you ssh then you will not have it set after you ssh (usually to localhost:n where n is usually not 0). BTW don't put the IP address in DISPLAY - just set it to DISPLAY=:0. BTW2 X is an awful heavy process to run if your aim is merely to run ASCII terminals. Instead use mintty (or rxvt) and -e ssh remote host instead. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.[67]: getting bash prompt takes 50 seconds
On 9/1/2010 8:35 AM, Andrey Repin wrote: + Did you tried to *uninstall* bash-completion? What changed such that bash-completion, which previously worked fine, no longer does? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.[67]: getting bash prompt takes 50 seconds
On 9/2/2010 11:03 PM, Reid Thompson wrote: On 9/1/2010 8:35 AM, Andrey Repin wrote: + Did you tried to *uninstall* bash-completion? What changed such that bash-completion, which previously worked fine, no longer does? Upstream changes. They're working on fixes. See recent email archives if you're interested in some details. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.[67]: getting bash prompt takes 50 seconds
On 9/2/2010 11:03 PM, Reid Thompson wrote: On 9/1/2010 8:35 AM, Andrey Repin wrote: + Did you tried to *uninstall* bash-completion? What changed such that bash-completion, which previously worked fine, no longer does? The biggest change i've seen is in the slowdown of ./configure and make -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The un-notified update of gcc4-4.3.4-3 cause setup failed(build date 2009-12-11 to 2010-08-15, caused file size mismatch)
Thank you Davek. Sorry for my poor English and poor expression. You're right, I'm installing cygwin to a new server from local package cache on my PC via net share. It's ok to avoid redownload existing files. Maybe it's better to shown the 'file size mismatch' message or other error messages (which occured in command line setup mode) too in GUI setup mode. Or, it will take more time to find out the error. ^_^ Dave Korn-9 wrote: On 02/09/2010 05:32, LiuYan 刘研 wrote: Today I try to setup cygwin on a new server, it keeps failed with a cyggcc_s-1.dll is missed error in the last post-install phase. I'm sorry it caused you a problem, I'm afraid setup.exe was smarter than I am and it spotted the difference when I hoped it wouldn't. I thought that it would be ok, since cyggcc_s-1.dll would already be installed, so it shouldn't have been looking to upgrade anything. Are you perhaps sharing a local package cache dir between both these machines, on a network shared drive or similar? I rename gcc4 directory to gcc4-old, reinstall gcc4 and libgcc1 package, it works ok finally. Right, that workaround should suffice. I wanted to avoid everyone who already had the package installed from having to redownload it because the only thing that changed was a couple of 'x' permission bits on a couple of the scripts. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/The-un-notified-update-of-gcc4-4.3.4-3-cause-setup-failed%28build-date-2009-12-11-to-2010-08-15%2C-caused-file-size-mismatch%29-tp29600561p29610882.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
On 2 September 2010 23:49, RISINGP1 wrote: My cygwin.bat: @echo off C: chdir C:\cygwin\bin REM bash --login -i REM pdksh -l -i start mintty -p 70,0 -t Console -e - Btw, you don't need cygwin.bat to start mintty; you can just put those parameters into a shortcut (or copy the one in the start menu and edit it): Target: C:\cygwin\bin\mintty -p 70,0 -t Console - That avoids a console window flashing up when starting it. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
