Who can tell me /usr/sbin/in.* belong to which packages?
$ ls /usr/sbin/in.* in.ftpd.exe in.rlogind.exe in.talkd.exein.tftpd.exe in.rexecd.exe in.rshd.exe in.telnetd.exe in.uucpd.exe My cygwin's packages info has lost. So I got nothing by performing cygcheck -f $ cygcheck -f /usr/sbin/in.tftpd This command print nothing to me. I have no way except looking for help here. Thank you guys. I just wanna know /usr/sbin/in.* belong to which packages. Please tell me the result of this command $ cygcheck -f /usr/sbin/in.* Thank you. -- 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: Who can tell me /usr/sbin/in.* belong to which packages?
OK, Thank you Corinna
I got it.
/usr/sbin/in.{service}.exe belongs to =inetutils-1.3.2-40.
In inetutils-1.5-4, this file is replaced with /usr/sbin/{service}.exe
E.g., /usr/sbin/in.tftpd.exe is replaced with /usr/sbin/tftpd.exe
I think that is why I can't find which package /usr/sbin/in.* belong to.
http://cygwin.com/packages/ is quite useful. :)
On Mon, Jul 7, 2008 at 5:37 PM, Corinna Vinschen
[EMAIL PROTECTED] wrote:
On Jul 7 14:12, kou yu wrote:
$ ls /usr/sbin/in.*
in.ftpd.exe in.rlogind.exe in.talkd.exein.tftpd.exe
in.rexecd.exe in.rshd.exe in.telnetd.exe in.uucpd.exe
My cygwin's packages info has lost. So I got nothing by performing cygcheck
-f
$ cygcheck -f /usr/sbin/in.tftpd
This command print nothing to me.
I have no way except looking for help here.
Not quite: http://cygwin.com/packages/
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.25-7: problem about bash completion
On Dec 23, 2007 1:26 PM, Christopher Faylor [EMAIL PROTECTED] wrote: On Sun, Dec 23, 2007 at 01:02:23PM +0800, kou yu wrote: o, maybe you are right. It's a good bet that she is. But I am a little confused. //server/share is the POSIX syntax for SMB share paths, but on windows the syntax is \\server\share. POSIX *allows* '//something' to have a special meaning. It doesn't state that it is necessarily the syntax for SMB share paths. And why on linux I input cd //usr/tab, the completion would not become slow, i.e. why on linux, the syntax //xxx/xxx would not be considered as remote SMB share. (except smbclient //server/share) Because a '//' has no special meaning on linux. Both '//server/share' and '\\server\share' are valid syntax for Windows. You can believe this or not but Cygwin's behavior is not going to change. In fact, if you simply say that this is not a bug of cygwin, but a feature, then I would believe you. cgf -- 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/ -- 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/
1.5.25-7: problem about bash completion
If I input: cmdname /dirname/tab then I get the normal completion output immediately. But if I input: cmdname //dirname/tab then I must wait for a long time for those completion output. And the terminal seems to be frozen, have not a single response. So, is this a bug of cygwin or bash on cygwin? Because my gentoo doesn't have this problem. cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.25-7: problem about bash completion
o, maybe you are right. But I am a little confused. //server/share is the POSIX syntax for SMB share paths, but on windows the syntax is \\server\share. And why on linux I input cd //usr/tab, the completion would not become slow, i.e. why on linux, the syntax //xxx/xxx would not be considered as remote SMB share. (except smbclient //server/share) On Dec 22, 2007 5:57 PM, Corinna Vinschen [EMAIL PROTECTED] wrote: On Dec 22 17:43, kou yu wrote: If I input: cmdname /dirname/tab then I get the normal completion output immediately. But if I input: cmdname //dirname/tab then I must wait for a long time for those completion output. And the terminal seems to be frozen, have not a single response. So, is this a bug of cygwin or bash on cygwin? Because my gentoo doesn't have this problem. This is Windows, not Linux. //server/share is the Windows syntax for remote SMB share paths. This feature is backed by the POSIX standard. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/ -- 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/
There is no prompt message if shared object file cannot open, when I was running a program.
Problem: when running a program from bash and the program requires a lib that is missing, I do not get any error message. Only a exit status of 128. Can I change this behavior? I've exhausted those help resources (include FAQ, User's Guide, mailing list archives and even google). The closer I have found so far is this thread: no message or dialog when a DLL is missing, its link is http://sourceware.org/ml/cygwin/2006-08/msg00895.html. But that thread disappointed me by ending up with nothing definited. The posters and replyers seemed to be regardless to this problem. 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? Failing with return code 128 is far less helpful, but printing to stderr (or whatever is eating off that pipe) is much more script-friendly than a GUI pop-up. -- 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/
