Re: Reading what should not!
Larry Hall (Cygwin) wrote: This is new behavior with 1.7 and it's there to mimic what one sees in Linux. I can't reproduce your reported results in Fedora 8. For me, if I am 'root', I can see the contents of 'foo.txt' just fine with the permissions you have set on it. I do not know how Fedora works, but on Kubuntu the user created when installing the SO is also 'root': one need only to use 'sudo...'. After typing the password it 'remains active' for about 15 minute. This mean that if I use 'sudo less foo.txt' when that pass. is active I do not need to retype it, and, as 'root', I can read that file. But if I open a new shell, in which the passwd is not yet 'active', trying 'sudo less...' asks for the passwd, which looks right to me. Why 'root' should read, for example, private mails of the other simple users of that PC? Cheers, Angelo. -- 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: Core dump on hello world.
Jerry DeLisle wrote: > gdb says: > (gdb) r > Starting program: /home/jerry/prs/test/a.exe > [New thread 162.0xa9] > [New thread 162.0x8e] > > Program received signal SIGILL, Illegal instruction. > set_fpu () at ./fpu-target.h:80 > 80 ./fpu-target.h: No such file or directory. > in ./fpu-target.h > (gdb) bt > #0 set_fpu () at ./fpu-target.h:80 Need an actual $eip value here, and the contents of your /proc/cpuinfo please. 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: Core dump on hello world.
Dave Korn wrote: > Jerry DeLisle wrote: > >> gdb says: >> (gdb) r >> Starting program: /home/jerry/prs/test/a.exe >> [New thread 162.0xa9] >> [New thread 162.0x8e] >> >> Program received signal SIGILL, Illegal instruction. >> set_fpu () at ./fpu-target.h:80 >> 80 ./fpu-target.h: No such file or directory. >> in ./fpu-target.h >> (gdb) bt >> #0 set_fpu () at ./fpu-target.h:80 > > Need an actual $eip value here, and the contents of your /proc/cpuinfo > please. Nah, hang on, I'll give the psychic debugging a go.I'm getting something the spirits are talking... or maybe it's just the beer... and they tell me: The problem is that the CPUID instruction in your virtual machine is returning some kind of bogus output that's leading set_fpu() to believe the CPU supports SSE, but the emulation in fact does not, and it blows up here: > 0x697826c4 : stmxcsr -0x14(%ebp) 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: Core dump on hello world.
Dave Korn wrote: > Nah, hang on, I'll give the psychic debugging a go. forehead, covering eyes, waves other hand out in front of me in a > mystical-looking way> I'm getting something the spirits are talking... or > maybe it's just the beer... and they tell me: The problem is that the CPUID > instruction in your virtual machine is returning some kind of bogus output > that's leading set_fpu() to believe the CPU supports SSE, but the emulation in > fact does not, and it blows up here: > >> 0x697826c4 : stmxcsr -0x14(%ebp) Also, is your CPU a VIA by any chance, maybe a C7? 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
sshd -- "Note that the CYGWIN=ntsec setting is required for public key authentication"
Hello all, I recently had to switch CYGWIN environment of sshd service from 'ntsec' to 'nontsec' (because of 'sed -i' breaking inherited access rights to some files used by native Windows apps). All seem to work fine after the change, including public key logins to modified sshd, but $subj quote from /usr/share/doc/Cygwin/openssh.README worries me a bit. Is the note still applicable? -- ...Bye..Dmitry. -- 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: Reading what should not!
On Mon, Sep 14, 2009 at 4:29 AM, Angelo Graziosi wrote: > I do not know how Fedora works, but on Kubuntu the user created when > installing the SO is also 'root': one need only to use 'sudo...'. After > typing the password it 'remains active' for about 15 minute. That makes no sense. "sudo" means "run as root". If you're already root, there's no need for sudo, and most systems don't even allow root to run the sudo command. In traditional UNIX, either you're root, in which case you have the full run of the box with no need to ask for extra permissions, or you're not. Secured OSes like SELinux change those rules, but you're no longer in the realm of general Linux at that point. It sounds to me like your Fedora created a user named "root" who is not really "root" (uid 0). Which might be a security thing, but is sure to lead to confusion. What does 'id' report? -- Mark J. Reed -- 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: Reading what should not!
Angelo Graziosi wrote: > Why 'root' should read, for example, private mails of the other simple > users of that PC? Root is the superuser. Root is the administrative account. Root can do anything. The sysadmin /has/ to be able to access all the files on a system, it is a necessary part of administering the system. If root can't read the user's private mailbox file, how can root back up that user's private mailbox file for them? (The ethical issues surrounding the guardianship, accountability and responsible use of this degree of power cannot be solved by technological means, so we don't even try to "fix it in the OS". If you want to keep confidential data on a machine where you are not root and where you cannot trust the root user to respect your privacy, you shouldn't put it there in the first place.) 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
Strange tar error with --format=ustar: value 4294967295 out of gid_t range 0..2097151
I need to send a collection of files to a Z/OS machine from a windows machine. When we were on Windows 2000, we just used "pax". But apparently Microsoft has discontinued pax in Win2003. So we searched for a solution. Cygwin tar SAID it would produce pax format files, but the Z/OS machine doesn't like them if they contain long file names. However, tar will ALSO produce ustar format, and pax on the mainframe is able to read those. So we were cooking with gas. Except on my usual development machine, where I get the error: E:\yduJ> c:\cygwin\bin\tar cf foo.tar --format=ustar foo /usr/bin/tar: value 4294967295 out of gid_t range 0..2097151 /usr/bin/tar: Exiting with failure status due to previous errors It works FINE on the official build machine, just not MINE. So I reran Cygwin setup and reinstalled and rebooted. No help. I started making all sorts of wrong guesses about this. Eventually I discovered a directory on my machine which DID tar up. Then I realized what was different: I had made or edited at least one file USING EMACS in all the other directories. Yep, added a file using emacs and the new directory couldn't be tarred either. I went and got emacs version 23.1.1 from gnu hoping it would be better, but it's not. Tar is version 1.21. I figured out a workaround, which is to say --group=1 to specify groups, so I'm OK now, but it would be nice not to need that, since it's only for my development machine. The build machine of course works only on the cvs checked out files and does not require this workaround. -- 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
Optional command -R of inetd service
Hi,I have the following problems now. 【use of cygwin】 I executed to use "Remote Command(rcp/rsh)" from Solaris to Windows and 【Problem】 Problem is "Stop" the system during File transfer and windows bat module moving. 【Factor】 The number of issues of remote commands(rcp/rsh) exceeded the upper bound connection number in the unit time of the inetd service, and processing stopped. When the inetd source code was confirmed, 「TOOMANY」 and「CNT_INTVL」were set as follows. ※ #define TOOMANY 40 #define CNT_INTVL 60 The following commands were executed from the command prompt. sc config inetd binPath= "C:\cygwin\usr\sbin\inetd.exe -R 200" net stop inetd net start inetd Processing stopped though the value was greatly set and the option -R was used. Can a set numerical value of 「TOOMANY」 and 「CNT_INTVL」 be changed by using an optional command -R ? -- 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: C++ script doesn't work using g++
Thanks for your answer Larry. I'll try in the same way you did. It's a pity
cygwin doesn't support borland c++.
Cheers,
Gery
> Date: Fri, 11 Sep 2009 15:57:22 -0400
> From: reply-to-list-only...@cygwin.com
> To: gameji...@hotmail.com
> Subject: Re: C++ script doesn't work using g++
>
> On 09/11/2009 02:49 PM, Gery Herbozo Jimenez wrote
>> I have a simple script:
>>
>> #include
>> #include
>> int main()
>> {
>> clrscr();
>> cout<<"Hallo";
>> getch();
>> }
>>
>> However it doesn't work under this command:
>>
>> g++ hallo.cpp -o hallo.exe
>>
>> It gives:
>>
>> In file included from
>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward/iostream.h:31,
>> from hallo.cpp:1:
>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward/backward_warning.h:32:2:
>> warning: #warning This file includes at least one deprecated or antiquated
>> header. Please
>> consider using one of the 32 headers found in section 17.4.1.2 of the C++
>> standard. Examples include substituting the header for the header for C++
>> includes, or
>> instead of the deprecated header . To disable this warning use
>> -Wno-deprecated.
>> hallo.cpp:2:19: conio.h: No such file or directory
>> hallo.cpp: In function `int main()':
>> hallo.cpp:6: error: `clrscr' undeclared (first use this function)
>> hallo.cpp:6: error: (Each undeclared identifier is reported only once for
>> each function it appears in.)
>> hallo.cpp:8: error: `getch' undeclared (first use this function)
>>
>> Someone knows why? I tested it under borland c++ (v.5) in windows and
>> works perfectly.
>
> That's because it's written to use Borland C++-specific facilities (i.e.
> it's not
> portable). Although there are a number of ways to address this, here's what
> I did:
>
> #include
> #include
>
> using namespace std;
>
> int main()
> {
> initscr();
> clear();
> refresh();
>
> cout<<"Hallo";
> cout<> getch();
> endwin();
> }
>
> g++ hallo.cpp -o hallo.exe -lcurses
>
> Of course, to make this work you'll need to install the ncurses-devel package.
>
> --
> 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?
_
Hay tantos ordenadores como personas. ¡Descubre ahora cuál eres tú!
http://www.quepceres.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: C++ script doesn't work using g++
Thanks Jeremy and yes, in the message I forgot to put the and respectively,
but my script has them and however it doesn't work. I now know cygwin doesn't
support borland c++, and thanks for the posts about it. I have to start working
under c++ now! more interesting and wonderful work :).
Gery Herbozo Jimenez wrote:
>
> I have a simple script:
>
> #include
> #include
> int main()
> {
> clrscr();
> cout<<"Hallo";
> getch();
> }
It looks like your include statements are missing what they are supposed
to include. I made a guess that they should be as follows:
#include
#include
> However it doesn't work under this command:
>
> g++ hallo.cpp -o hallo.exe
>
> It gives:
>
> In file included from
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward/iostream.h:31,
> from hallo.cpp:1:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward/backward_warning.h:32:2:
> warning: #warning This file includes at least one deprecated or antiquated
> header. Please
> consider using one of the 32 headers found in section 17.4.1.2 of the C++
> standard. Examples include substituting the header for the header for C++
> includes, or
> instead of the deprecated header . To disable this warning use
> -Wno-deprecated.
> hallo.cpp:2:19: conio.h: No such file or directory
> hallo.cpp: In function `int main()':
> hallo.cpp:6: error: `clrscr' undeclared (first use this function)
> hallo.cpp:6: error: (Each undeclared identifier is reported only once for
> each function it appears in.)
> hallo.cpp:8: error: `getch' undeclared (first use this function)
>
> Someone knows why? I tested it under borland c++ (v.5) in windows and works
> perfectly.
>
> Any hint is grateful.
It's been a decade since I last used any significant C++, but it appears
that conio.h is missing. Googling around tells me that conio is a
Borland extension, so it probably won't be available by default for g++.
There appears to be a SourceForge project to provide an equivalent for
MinGW however:
http://conio.sourceforge.net/
This blog post looks like it might also be helpful:
http://www.technology-included.co.cc/2009/05/conioh-on-gcc-linux.html
The file it instructs you to download doesn't work for me with g++ under
Cygwin though. It causes the compiler to report a bunch of errors.
Maybe you'll have better luck.
-Jeremy
--Archivo adjunto de mensaje reenviado--
Date: Fri, 11 Sep 2009 20:04:19 +
From: gchica...@sbcglobal.net
To: cygwin@cygwin.com
Subject: Re: C++ script doesn't work using g++
On 2009-09-11 18:49Z, Gery Herbozo Jimenez wrote:
>
> int main()
> {
> clrscr();
> cout<<"Hallo";
> getch();
> }
This message:
http://www.cygwin.com/ml/cygwin/1999-09/msg00326.html
mentions the danger of mixing getch() with C++ streams,
and explains why Cygwin doesn't provide "conio.h".
Consider using ncurses instead.
--Archivo adjunto de mensaje reenviado--
Date: Sat, 12 Sep 2009 00:00:31 +0200
From: christian.fra...@t-online.de
To: cygwin@cygwin.com
Subject: [1.7] binutils-2.19.51-1: ld -r bug ?
Testing build of grub 1.97 beta on Cygwin 1.7, I found that the grub
.mod files are much larger than on 1.5. The modules are build by 'ld -r'
(and later converted to ELF).
The root of the problem is that the binutils-2.19.51-1 ld behavior
differs from previous 1.5 binutils. The new ld increases the size of
each segment by the size of the previous segment. Bug?
Testcase:
$ cat segm.c
void text() { __asm__(".space 104"); }
char data[256] = "DATA";
const char rdata[16] = "RDATA";
$ gcc -c segm.c
cygwin-1.5:
$ cygcheck -f /bin/ld
binutils-20080624-2
$ ld -r -o segm-r5.o segm.o
cygwin-1.7:
$ cygcheck -f /bin/ld
binutils-2.19.51-1
$ ld -r -o segm-r7.o segm.o
$ size segm.o segm-*.o
text data bss dec hex filename
128 256 0 384 180 segm.o
128 256 0 384 180 segm-r5.o
512 384 400 1296 510 segm-r7.o
$ objdump -s segm-r*.o
segm-r5.o: file format pe-i386
Contents of section .text:
5589e500 U...
...
0060 005d c3909090 ...]
Contents of section .data:
0080 44415441 DATA
...
0170
Contents of section .rdata:
0180 52444154 4100 RDATA...
segm-r7.o: file format pe-i386
Contents of section .text:
5589e500 U...
...
0060 005d c3909090 ...]
Contents of section .data:
...
0080 44415441 DATA
...
0170
Contents of section .rdata:
...
0180 52444154 4100 RDATA...
There are no related changes in the builtin linker scripts (ld --verbose
-r).
Christian
--Archivo adjunto de mensaje reenviado--
Date: Sat, 12 Sep 2009 02:02:40 +0100
From: dave.korn.cyg.
Re: Reading what should not!
Mark J. Reed wrote: That makes no sense. "sudo" means "run as root". If you're already root, there's no need for sudo, and most systems don't even allow root to run the sudo command. I do not mean that 'root' need 'sudo'. It sounds to me like your Fedora I do not have Fedora but Kubuntu (8.04 and 9.04). On Kubuntu the user created in the installation step, say 'pippo', is also 'root' in the sense that 'pippo' needs 'sudo' (or 'sudo su') for administrative usage. Cheers, Angelo. -- 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: Reading what should not!
Mark J. Reed wrote: Administrative users on Windows are treated as equivalent to root by Cygwin. I know that. If you're saying that admin users should have to use sudo or equivalent to gain elevated access in Cygwin, then that's a feature request. Does it match what Windows does? Outside of UAC in Vista I'm unaware of Administrators having to do anything to activate their privileges. I never said that. Cheers, Angelo. -- 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: Reading what should not!
On Mon, Sep 14, 2009 at 10:26 AM, Angelo Graziosi wrote: > I do not have Fedora but Kubuntu (8.04 and 9.04). On Kubuntu the user > created in the installation step, say 'pippo', is also 'root' in the sense > that 'pippo' needs 'sudo' (or 'sudo su') for administrative usage. OK, then, big difference. 'pippo' is not root, pippo is able to do things as root when needed. Administrative users on Windows are treated as equivalent to root by Cygwin. If you're saying that admin users should have to use sudo or equivalent to gain elevated access in Cygwin, then that's a feature request. Does it match what Windows does? Outside of UAC in Vista I'm unaware of Administrators having to do anything to activate their privileges. -- Mark J. Reed -- 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: subversion hangs on svn up using 1.6.4 & 1.6.5
On 9/13/2009 1:46 PM, John Bito wrote: I'm not sure how to diagnose this problem, as svn up produces no output and svn admin recover says: svnadmin: Expected repository format '3' or '5'; found format '10' I imagine that the format 10 indicates that the repository is corrupt. Do you have any suggestions for repairing it? "svnadmin recover" is for recovering a repository, not a working copy. Which are you trying to do? There's some possibility that subclipse was what created this working copy, though I was pretty sure I used Cygwin SVN to update it most recently. I tried svn up with Cygwin SVN 1.6.4 and then upgraded to Cygwin SVN 1.6.5, both hang with no output. Then I tried svnadmin recover .svn which gives the message above. What does "svn st" say? I use "svn up" against an http repository all the time. Also, both releases of SVN passed the test suite, which runs against a local FSFS and BDB repository, as well as svn:// and http:// repositories. If there's not a clear path to repairing my working copy, do you know of any guidance for moving work from a broken working copy to a new checkout so that svn up will merge changes/flag conflicts? I usually fix this by replacing all the .svn directories in my working copy. I use commands like the following. Note, this is from memory, so check them yourself before running. % cd /my/working/copy % find . -name .svn -prune -print0 | xargs -0 rm -fr % cd /tmp % svn co http://my/repository/path svn-tmp % cd svn-tmp % find . -name .svn -prune -print0 | \ rsync -avri --files-from=- --from0 ./ /my/working/copy % cd /my/working/copy % rm -fr /tmp/svn-tmp % svn status -- David Rothenberger daver...@acm.org I'll burn my books. -- Christopher Marlowe -- 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: C++ script doesn't work using g++
On Mon, Sep 14, 2009 at 02:09:59PM +, Gery Herbozo Jimenez wrote: >Thanks Jeremy and yes, in the message I forgot to put the and >respectively, but my script has them and however it doesn't work. I >now know cygwin doesn't support borland c++, and thanks for the posts >about it. I have to start working under c++ now! more interesting and >wonderful work :). There is no reason to suspect that a system which emulates UNIX would automatically recognize the libraries of a DOS/Windows C compiler. 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: Reading what should not!
Angelo Graziosi wrote on Monday, September 14, 2009 9:27 AM: > Mark J. Reed wrote: >> That makes no sense. "sudo" means "run as root". If you're already >> root, there's no need for sudo, and most systems don't even allow root >> to run the sudo command. > > I do not mean that 'root' need 'sudo'. > >> It sounds to me like your Fedora > > I do not have Fedora but Kubuntu (8.04 and 9.04). On Kubuntu the user > created in the installation step, say 'pippo', is also 'root' in the > sense that 'pippo' needs 'sudo' (or 'sudo su') for administrative usage. On Kubuntu (or any other Ubuntu-derived distro, AFAIK), the root user is disabled by default; the only way to get root priveleges is to use sudo, which is set up to ask for your password (whatever user you're running as when you execute sudo). So there is no difference between being an Administrator on Cygwin 1.7 and having root priveleges on Kubuntu; it's just that on Kubuntu, you have to type in your password to get root priveleges, while on Cygwin, you just have to be an Administrator user. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.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: Strange tar error with --format=ustar: value 4294967295 out of gid_t range 0..2097151
On 9/14/09, Judy Anderson wrote: .. snip .. > Except on my usual development machine, where I get the error: > > E:\yduJ> c:\cygwin\bin\tar cf foo.tar --format=ustar foo > /usr/bin/tar: value 4294967295 out of gid_t range 0..2097151 > /usr/bin/tar: Exiting with failure status due to previous errors > > It works FINE on the official build machine, just not MINE. So I reran > Cygwin setup and reinstalled and rebooted. No help. Did you run mkpasswd and mkgroup on your machine? i think an unknown user or group gets an id of 4294967295 Lee -- 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: Reading what should not!
On Mon, Sep 14, 2009 at 4:29 AM, Angelo Graziosi wrote: > Larry Hall (Cygwin) wrote: >> >> This is new behavior with 1.7 and it's there to mimic what one sees in >> Linux. I can't reproduce your reported results in Fedora 8. For me, if I >> am 'root', I can see the contents of 'foo.txt' just fine with the >> permissions >> you have set on it. > > I do not know how Fedora works, but on Kubuntu the user created when > installing the SO is also 'root': one need only to use 'sudo...'. sudo allows non-root users to run commands as root, or to get shells as root. > After typing the password it 'remains active' for about 15 minute. "remains active" meaning that the sudo infrastructure remembers that you have validated yourself to it already, and don't need to do it again. > This mean that > if I use 'sudo less foo.txt' when that pass. is active I do not need to > retype it, and, as 'root', I can read that file. You don't need to retype it because sudo remembers that you've typed it already, so lets you become root anyway. You can read the file because you're root - that has nothing to do with the password. The password only affects the steps where you're gaining root privileges, it has nothing to do with what you can do once you have them. > But if I open a new shell, > in which the passwd is not yet 'active', trying 'sudo less...' asks for the > passwd, which looks right to me. The sudo password caching can be disabled entirely, enabled per-user, or enabled per-tty (basically per-shell). sudo can also be configured to either require the password of the user or the password of root to launch commands as root. > Why 'root' should read, for example, private mails of the other simple users > of that PC? As Dave Korn said, because he needs to be able to. You're confusing the process of *becoming* root with what root can do. Becoming root requires a password, of course! On a system where you become root using sudo, that password is usually the user's password, but it can also be root's password, depending on the system's config. But once you've become root, you can do whatever you want, including deleting every file and directory on the disk, and no one can stop you. To prove that the "password becoming active" is just part of the inner workings of sudo, you could just try out "sudo -i" to get an interactive shell as root - you'll see that you can "less" the file just fine, and will continue to be able to for as long as you stay logged in as root. ~Matt -- 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
GNU screen 4.0.3-1 -- Spawns a screen.exe cmd window when launched
When I launch screen by typing 'screen' at the basic Cygwin bash prompt, a screen.exe cmd window launches and stays open for the entire screen session. I only see this behavior with Windows 7. -- Joel Eidsath -- 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: GNU screen 4.0.3-1 -- Spawns a screen.exe cmd window when launched
2009/9/14 Joel Eidsath: > When I launch screen by typing 'screen' at the basic Cygwin bash prompt, a > screen.exe cmd window launches and stays open for the entire screen session. > > I only see this behavior with Windows 7. Cygwin 1.7 has a workaround for the Windows 7 bug that causes this. It won't be ported back to 1.5. 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: Re: GNU screen 4.0.3-1 -- Spawns a screen.exe cmd window when launched
The 1.7 beta works for me. Thank you. -- Joel Eidsath -- 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: ClamAV antivirus v.0.95 - When?
Alexey Lyubimov schrieb: The current version of the Cygwin's port of ClamAV is 0.94-2. The canonical stable version is 0.95.2. Freshclam says that the installed version is OUTDATED, and clamav.net/support/faq recommends to upgrade immediately. So, what about the newest version for Cygwin? Is it on the way? PS: I can not use native Windows port of clamav because it requires XP and I'm running 98SE. I updated it for cygwin-1.7 (release-2 area) at 2009-06-11. I don't make any 1.5 updates anymore. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: PostgerSQL startup script bug
Huang Bambo schrieb:
The cygwin 1.7 don't need “server” tag in CYGWIN environment but the
start up of postgresql 8.2.11 checked this tag.
code:
131 check_cygserver() {
132 # Check for running cygserver processes first.
133 if ps -ef | grep -v grep | grep -q cygserver
134 then
135 echo -n "- cygserver OK - "
136 # echo "OK cygserver running"
137 else
138 echo "ERROR cygserver must be started"
139 echo cygrunsrv -S cygserver
140 exit 1
141 fi
142 # check for CYGWIN containing server
143 if [ -n "${CYGWIN%server}" ]
144 then
145 echo "ERROR CYGWIN must contain server for cygserver to work properly"
146 exit 1
147 fi
148 }
149
from 142 to 147 is not needed in cygwin 1.7
Thanks for the heads up.
This package is still from 1.5.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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
tcl/tk/expect/dejagnu/gdb/insight [Was: Re: [PATCH] Define _TIMEVAL_DEFINED consistently whenever defining timeval.]
Redirected from cygwin-patches:
Dave Korn wrote:
> Granted that the whole _TIMEVAL_DEFINED/__USE_W32_SOCKETS thing is basically
> an ugly and undesirable hack, but until we have a plan to fix the whole
> tcl/tk/expect/dejagnu/gdb/insight combo (as well as gnat), I figure we have to
> live with it, and so it should at least be correct consistent and complete.
>From this thread:
http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html
I thought most people either were in favor of, or at least not opposed
to, "fixing" the */tk/*/insight issue by switching to an X-based tk. It
was just waiting on enough cgf-tuits (and, perhaps, the long-delayed gdb
7.0 release and/or Insight 7.0).
FWIW, I recently had to build my own tcl/tk and python (with pytk)
because I needed the Python Imaging Library but I couldn't get it to
work properly with cygwin-standard python and tk. (That combo used to
work, but it was a very old version of python, and cygwin-1.5. No longer.)
Anway, tcl-8.5.6 and tk-8.5.6 built easily on a bog-standard cygwin-1.7
system using the cygports derived from the Cygwin Ports project. I
couldn't just use the Cygwin Ports binaries because IIRC they depend on
other Cygwin Ports packages not available in the normal cygwin
distro...and I didn't want to pull in more than I needed.
'Course, this broke my insight since I didn't bother to rebuild gdb.
But, if it would help, I can post these cygport files (which may differ
very slightly from the Cygwin Ports-supplied and -dependent ones).
While doing that, I was curious to see what else this change would break
(e.g. what else relies on tcltk):
suite3270/tcl3270
brltty/tcl-brlapi
parrot/parrot-languages
db/db*/tcl-db*
git/gitk
git/git-gui
expect
WordNet
ruby
catgets
gdb (e.g. insight)
python
which, honestly, isn't very much. I'd be concerned about all those
tcl-db${old_version} packages -- but it looks like there are no
in-distro users of them. That leaves gdb, ruby, python, git, and parrot
-- all of which have active maintainers. Plus suite3270 and brltty,
which I'm not sure about.
--
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: Core dump on hello world.
On 09/14/2009 02:04 AM, Dave Korn wrote: Dave Korn wrote: Nah, hang on, I'll give the psychic debugging a go. I'm getting something the spirits are talking... or maybe it's just the beer... and they tell me: The problem is that the CPUID instruction in your virtual machine is returning some kind of bogus output that's leading set_fpu() to believe the CPU supports SSE, but the emulation in fact does not, and it blows up here: 0x697826c4: stmxcsr -0x14(%ebp) Also, is your CPU a VIA by any chance, maybe a C7? No, its an AMD Phenom II. However, your hints were correct. I disabled the VirtualBox System::VT-x/AMD-V features and the problem goes away. What Crystal Balls you have! :) Jerry -- 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: emacs installed but won't run
Thank you for your help. "cygcheck emacs" produced the output below. After I used setup to install the "lib" and "X11" packages, I am happy to report I have a working emacs. However, (1) Although "info emacs" works, C-h does not provide any help options (2) C-x C-c does not exit emacs, although M-x-save-buffers-and-exit does * output from cygcheck before fix * Found: C:\cygwin\bin\emacs.exe C:\cygwin\bin\emacs.exe Error: could not find libICE.dll Error: could not find libSM.dll Error: could not find libX11.dll Error: could not find libXext.dll Error: could not find libXpm.dll Error: could not find cygncurses6.dll C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygjpeg6b.dll C:\cygwin\bin\cygpng12.dll C:\cygwin\bin\cygz.dll C:\cygwin\bin\cygtiff3.dll -- 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
