Re: .profile not sourced?
On 6 April 2011 11:04, David Sastre wrote:
>> > On 4/5/2011 4:47 PM, philippe roux wrote:
>> >> I have a file ~/.profile which contains some alias like
>> >> and ./bash_profile file containing the lines
>
> When using bash as a login shell, the existence of .bash_profile
> prevents from .profile being sourced.
True, but Philippe said he had this in .bash_profile:
# source the users profile if it exists
if [ -f "${HOME}/.profile" ] ; then
source "${HOME}/.profile"
fi
Might be an idea for base-files actually, allowing for bash-specific
settings in .bash_profile while having settings common across shells
in .profile.
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: [1.7.9] bash: warning: setlocale: LC_COLLATE: cannot change locale (FR)
2011/4/5 Frédéric Bron: >> You mean after setting the locale in the mintty options? > > Yes > >> I don't think it's anything to do with the update. There's been no >> relevant change, and there's no good reason why Cygwin would set a >> locale like that. A valid one would be 'fr_FR'. I'd suspect some other >> software you installed or updated around the same time. Another Unix >> environment perhaps? > > Never mind. It is not working fine. I assume s/not/now/, but in any case it would still be helpful if you could confirm that the LANG=FR setting did come from the Windows environment, e.g. using the 'set' command in a Command Prompt. Even better if you had an idea where the setting came from, in case others stumble across this in future. Regards, 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: Python: subprocess running rsync causes broken socket in telnetlib
On Fri, Nov 12, 2010 at 16:19, David Antliff wrote:
>
> I'm reporting a problem I see on Cygwin because I do not see the same
> behaviour on Ubuntu Linux - both systems are running Python 2.6.5.
>
> I have a script that opens a long-term telnet connection (telnetlib)
> to a remote host. There is an object called Telnet().socket that is
> created and represents an active socket connection to the remote host,
> once the right telnetlib calls are made.
>
> Then the script uses subprocess to do something else (the line is
> actually longer than this but I've simplified it to the most basic
> version that exhibits the problem):
>
> process = subprocess.Popen("rsync", stdout=subprocess.PIPE)
>
> On Cygwin 1.7.7, this does something nasty to the completely unrelated
> yet existing telnetlib socket so that any further attempts to read or
> write from this socket raise an exception:
>
> File "/usr/lib/python2.6/telnetlib.py", line 280, in write
> self.sock.sendall(buffer)
> File "", line 1, in sendall
> socket.error: [Errno 32] Broken pipe
>
> On Linux, this doesn't happen at all.
>
> I've tried a few other programs via subprocess like "cat" and "ssh"
> but they don't seem to cause this problem - only "rsync" does so far.
> There may be others but I haven't found them.
>
> If anyone is prepared to look into this I have attached a small python
> script (bug.py) that demonstrates the problem. The error returned in
> this case is "113: Software caused connection abort", but the end
> result is the same - the socket is broken by the call to subprocess &
> rsync:
>
> $ python bug.py
> ('telnet', '220 mx.google.com ESMTP w42sm3212723wfh.15\r\n')
> ('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n')
> ('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
> ('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996')
> Traceback (most recent call last):
> File "bug.py", line 38, in
> print("telnet", t.read_eager())
> File "/usr/lib/python2.6/telnetlib.py", line 370, in read_eager
> self.fill_rawq()
> File "/usr/lib/python2.6/telnetlib.py", line 516, in fill_rawq
> buf = self.sock.recv(50)
> socket.error: [Errno 113] Software caused connection abort
>
> If you edit the script and set 'crash' to False, you'll see that the
> script completes without error:
>
> $ python bug.py
> ('telnet', '220 mx.google.com ESMTP i16sm3108013ibl.0\r\n')
> ('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n')
> ('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
> ('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250')
>
> And on Linux:
>
> $ python bug.py
> ('telnet', '220 mx.google.com ESMTP i16sm3106343ibl.18\r\n')
> ('ssh', 0, 'OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009\n')
> ('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n')
> ('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996')
> ('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250')
This bug is still present in Cygwin 1.7.8:
$ uname -a
CYGWIN_NT-5.1 pc770 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 Cygwin
rsync is still version 3.0.7.
What additional information may be required? Let me know and I'll
assist with debugging, especially as the implications of this bug may
be quite serious (leaking file descriptors?)
-- David.
--
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: NTFS write-protect flag translation (tar? rsync?) only one-way?
-Original Message- From: Cygwin On Behalf Of Larry Hall (Cygwin) Sent: Wednesday, 6 April 2011 11:04 AM Subject: Re: NTFS write-protect flag translation (tar? rsync?) only one-way? >On 4/5/2011 8:35 PM, Christian Gelinek wrote: >> From: Cygwin On Behalf Of Larry Hall (Cygwin) >>> On 4/5/2011 3:36 AM, Christian Gelinek wrote: It appears that when tar reads files for adding to archives, it correctly interprets the Windows-set "R" attribute, which is also seen by ls under Cygwin. After extracting the files using tar though, only Cygwin's ls command seems to be aware of the read-only attribute; the attrib command (as well as Explorer and other Windows-apps) see and handle the file as being writeable. >>> >>> The read-only attribute is a "Windows" thing. Cygwin's utilities focus on >>> supporting POSIXy/Linuxy ways of doing things. You can't expect Cygwin's >>> tools to manage all of Window's permission facilities in the same way as >>> Windows does. The read-only flag is one case where you'll see a divergence. >>> If you need that flag set, you'll need your own wrapper to set it based on >>> the POSIX (or ACL) permissions. The read-only attribute really is quite >>> anachronistic though IMO. It conflicts with the more powerful ACLs. If >>> you have the option, it's better not to use that flag. >> >> IMO the behaviour is inconsistent if the flag is used/interpreted on one (the >> read) operation but NOT being written/changed on the other (write) operation. >> My approach would be either drop it completely or support it on both ends >> (the preferred option). > >Actually, the read-only attribute is not used by Cygwin to determine POSIX >permissions. According to what I have seen, the command attrib +R wp.txt changes ONLY the read-only flag - when I look at the Security page of the file properties dialog in Windows Explorer, the ACLs are not modified by attrib. Still Cygwin would see the file as read-only after the attrib call (please see my original post for the complete sequence of commands). >> By the looks of it (see >> http://sourceware.org/ml/cygwin/2002-05/msg00317.html), this problem has >> been addressed and potentially solved before, so I wonder if something is >> broken here. > >No, nothing is broken. Things have changed since 2002. If you want the gory >details, you can look in the email archives. The short of it is, making >read-only, Windows ACLs, and POSIX permissions all agree is overly >complicated. So we've dropped read-only support now. But AFAIK (see above) only for write operations. I also agree that there is a complicating overlap between the read-only attribute and the ACLs. Nevertheless, most Windows programs honour the read-only flag and Explorer can display a column listing such attributes as opposed to effective ACL permissions. The Samba server struggles with similar problems, as it also has to translate between POSIX and Windows permissions. Samba's solution is to emulate ACLs AND the read-only flag. It would be interesting how Samba treats changes to the read-only flag done by Windows, how it translates them to Linux permissions and back to Windows (does it change ACLs as well?). When I've got some time, I'll look into this. >> The background to all this is that I am using RCS (I know, almost as >> anachronistic as the read-only attribute, but that's dictated by my >> workplace) under both Windows and Linux and RCS relies heavily on the >> read-only attribute of files to be correct. IMO, it wouldn't hurt if the >> Cygwin tools would write the Windows read-only attribute when they create a >> Cygwin read-only file? > >Cygwin has a package for RCS. Perhaps that could solve your problem? Thanks for pointing that out, I will have a look at that as well. Regards, Christian -- 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: Utility: winln, a drop-in replacement for ln(1)
Le 06/04/2011 19:39, Daniel Colascione a écrit : On 4/6/2011 1:26 AM, Andy Koppe wrote: - Native symbolic links require administrator privileges and aren't available at all before Vista. They don't require administrator privilege per se: just SeCreateSymbolicLinkPrivilege, which can be granted to normal user accounts via local security policy. The easiest way to grant SeCreateSymbolicLinkPrivilege is to start gpedit.msc, go down to "Windows Settings"->"Security Settings"->"Local Policies"->"User Rights Assignment", then find "Create symbolic links" and add whatever users and groups you want[1]. unfortunatelly, gpedit.msc isn't available under Windows Vista Home Edition. however, cygwin provide editright for that purpose, don't remember the windows counterpart ? editrights -a SeCreateSymbolicLinkPrivilege -a user should work... Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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: Utility: winln, a drop-in replacement for ln(1)
On 6 April 2011 18:39, Daniel Colascione wrote: > On 4/6/2011 1:26 AM, Andy Koppe wrote: >> >> On 4 April 2011 21:30, Daniel Colascione wrote: >>> >>> Attached is a small program that behaves very similarly to ln(1), but >>> that >>> works with Windows hard and symbolic links instead of Cygwin ones. >>> Successful use of this program requires Vista or newer, a user with >>> SeCreateSymbolicLinkPrivilege, and a symlink evaluation policy that >>> allows >>> the kind of symbolic link you'd like to create. If these conditions are >>> met, however, this program becomes useful because it can create symbolic >>> links that work equally well for Cygwin and non-Cygwin programs. Because >>> its argument handling is practically identical to that of coreutils ln, >>> winln can be used via a simple shell alias (or PATH prefixing, if you're >>> feeling bold). >> >> Very nice, and much better than faffing about with 'cmd /c mklink' and >> cygpath. > > Thanks for taking a look. > >> - Coretools ln also creates native Windows hard links, via Cygwin's >> link() function. > > Yes, but I wanted winln to match ln's behavior, and that requires using hard > links by default. So yes, there's a bit of overlap. Yeah, it was mostly for the benefit of others to point out that Cygwin hard links already are native anyway. It certainly makes sense to have them in winln too for the sake of symmetry with ln, but you could just implement them as link() instead of doing it the hard way. >> - Native symbolic links require administrator privileges and aren't >> available at all before Vista. > > They don't require administrator privilege per se: just > SeCreateSymbolicLinkPrivilege, which can be granted to normal user accounts > via local security policy. The easiest way to grant > SeCreateSymbolicLinkPrivilege is to start gpedit.msc, go down to "Windows > Settings"->"Security Settings"->"Local Policies"->"User Rights Assignment", > then find "Create symbolic links" and add whatever users and groups you > want[1]. Btw, any idea why they were restricted in that way? >> - 'cmd /c mklink /j' allows to create directory junction points >> without administrator privileges. Junction points are more or less >> equivalent with symbolic links, and the 'linkd' utility from the >> Windows Reource Kit Tools even allows to create them on XP. Hence it >> might be useful for winln to fall back to junction points when >> symbolic links aren't available. > > That's a possibility, but I'm worried about that issue triggering bugs in > other programs --- IIRC, many programs would treat the junction point as a > normal directory and get into unbreakable loops, or recursively delete the > pointed-to tree. Maybe that's fixed now. Don't directory symbolic links have the same issue? And are you talking about Cygwin programs or native ones? FWIW, Cygwin treats junction points as symbolic links. >> - Native symbolic links obviously point at Windows paths, which means >> they end up pointing at the wrong thing if the meaning of their >> original POSIX path changes, in particular due to changing mount >> points or Cygwin symlinks in the original path. > > Right. That's an explicit tradeoff we have to make. Yep. > I run with an identity mapping from / to C:\ What do you mean by that? >> - 'winln' always creates a link to the absolute Windows path when >> given a relative path. > > No it doesn't. Relative links work fine --- cmd /c dir reports them as > relative, anyway. Sorry, you're right, must have confused myself in testing. Here's a real issue though: you're using MultiByteToWideChar with the thread codepage to translate relative paths, which is rather unlikely to be the same as the Cygwin filesystem charset (which defaults to UTF-8), resulting in stuff like this: $ ./winln -s foo bár $ ls -l ... lrwxrwxrwx 1 Andy None 3 Apr 6 20:35 bár -> foo This problem can be addressed by using mbstowcs() to do the conversion, after first selecting the correct charset with setlocale(LC_CTYPE, ""). Even with that, however, you're still missing out on certain tricks in Cygwin filename conversion, in particular the replacement of characters such as ':' that are disallowed in Windows filenames with codepoints in the Unicode private range. Therefore, if at all possible, you should use cygwin_create_path() for all paths. What's the reason for treating relative paths specially? Finally, what's with the bug referred to here? /* Work around a bug that causes Cygwin to resolve the path if it ends in a native symbolic link. Note that this bug makes symlinks-to-symlinks point to the ultimate target, and there's no good way around that. Regards, 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: Email "hangs"
I have installed the SSL and the EMAIL packages. Normal network activities (like nslookup) seem to work fine. I have configured my email.conf and set EDITOR=VI. However, when I issue the EMAIL command, it just hangs, e.g., [11:24 AM] # email -V -c ~/.email.conf -t -- Opened config /cygdrive/c/users/furashg/.email.conf and then it just hangs there. This is my .email.conf file # This is the DEFAULT configuration file for email. # # Please CHANGE THE VALUES below to suit your environment. # Don't forget to set the shell environment variable EDITOR # SMTP Server and Port number you use SMTP_SERVER = 'smtp.gmail.com' SMTP_PORT = '587' # If you'd rather use sendmail binary, specify it and the # command line switches to use, here. If you have both # this option and SMTP_SERVER set, SMTP_SERVER will be of # higher priority than SENDMAIL. #SENDMAIL_BIN = '/usr/lib/sendmail -t -i' # Your email address: If you'd like To have your name to # show in the from field instead of just your email address, # then keep the format below and edit it to your email # and name. MY_NAME = 'Gary Furash' MY_EMAIL = 'furashg...@gmail.com' #REPLY_TO = '' # If your mail server uses SSL or TLS in order to create # a secure communication, set this to "true". Only very # simple TLS is implemented at this time. In other words, # there is no way to load your own certs just yet. USE_TLS = 'true' # Signature file and settings: Where is the signature file # You can comment this out if you do not like signatures # SIGNATURE_FILE = '&/email.sig' # This is where you store your address book... If you don't # want address book functionality, just comment it out and # use regular email addresses. ADDRESS_BOOK = '&/email.address.template' # If you would like to have a copy Of your final email saved # after it is sent, please specify a directory to save # it in below... If not, just comment this field out and it # won't save a sent file other wise, it will save it as # email.sent in the directory below # SAVE_SENT_MAIL = '~' # With email, temporary files are stored with a random name # Starting with .EM. You must specify which directory you # would like these temporary files stored while email is in # Operation... After email is done executing, it will remove # Every temporary file it used. The most common storage area # for temporary files system wide is the /tmp directory # if TEMP_DIR is not set, you can set the environment variable # TMPDIR. If that is not set, email will just use /tmp TEMP_DIR = '/tmp' # You should put the absolute path of your GPG binary # In this variable. If you do not know the absolute path # just putting "gpg" will suffice if GPG is in your PATH # environment variable path. # GPG_BIN = '/usr/bin/gpg' ### # You can bypass email asking you for a password for gpg # when you are encrypting or signing emails if you store # it here. Keep this safe! Make sure that people can't # read your personal ~/.email.conf file if you're storing # your password here! ### # GPG_PASS = ### # You can use SMTP_AUTH with email. You just need to # specify which type of SMTP AUTH you will use. Email # support two types of SMTP AUTH: LOGIN and PLAIN. # Typically, LOGIN is the most used amongst SMTP servers. # If you are unsure, ask your ISP. ### SMTP_AUTH = 'LOGIN' ### # Setting your SMTP username is MANDITORY. Please # uncomment the option below and set your username in order # to use SMTP AUTH ### SMTP_AUTH_USER = 'furashg...@gmail.com' #
Re: Utility: winln, a drop-in replacement for ln(1)
On 4/6/2011 1:26 AM, Andy Koppe wrote: On 4 April 2011 21:30, Daniel Colascione wrote: Attached is a small program that behaves very similarly to ln(1), but that works with Windows hard and symbolic links instead of Cygwin ones. Successful use of this program requires Vista or newer, a user with SeCreateSymbolicLinkPrivilege, and a symlink evaluation policy that allows the kind of symbolic link you'd like to create. If these conditions are met, however, this program becomes useful because it can create symbolic links that work equally well for Cygwin and non-Cygwin programs. Because its argument handling is practically identical to that of coreutils ln, winln can be used via a simple shell alias (or PATH prefixing, if you're feeling bold). Very nice, and much better than faffing about with 'cmd /c mklink' and cygpath. Thanks for taking a look. - Coretools ln also creates native Windows hard links, via Cygwin's link() function. Yes, but I wanted winln to match ln's behavior, and that requires using hard links by default. So yes, there's a bit of overlap. - Cygwin link() directly invokes the NT API, which I think avoids some filename restrictions at the Win32 level. That's a good point. I haven't run into these issues myself, but maybe the next version of winln can also use the native API. - winln doesn't have the .exe magic where links to .exes automatically have .exe appended if it's not already present. Good point. Thanks. - Native symbolic links require administrator privileges and aren't available at all before Vista. They don't require administrator privilege per se: just SeCreateSymbolicLinkPrivilege, which can be granted to normal user accounts via local security policy. The easiest way to grant SeCreateSymbolicLinkPrivilege is to start gpedit.msc, go down to "Windows Settings"->"Security Settings"->"Local Policies"->"User Rights Assignment", then find "Create symbolic links" and add whatever users and groups you want[1]. - 'cmd /c mklink /j' allows to create directory junction points without administrator privileges. Junction points are more or less equivalent with symbolic links, and the 'linkd' utility from the Windows Reource Kit Tools even allows to create them on XP. Hence it might be useful for winln to fall back to junction points when symbolic links aren't available. That's a possibility, but I'm worried about that issue triggering bugs in other programs --- IIRC, many programs would treat the junction point as a normal directory and get into unbreakable loops, or recursively delete the pointed-to tree. Maybe that's fixed now. - Native symbolic links obviously point at Windows paths, which means they end up pointing at the wrong thing if the meaning of their original POSIX path changes, in particular due to changing mount points or Cygwin symlinks in the original path. Right. That's an explicit tradeoff we have to make. I run with an identity mapping from / to C:\, however, so the issue never comes up in practice. - 'winln' always creates a link to the absolute Windows path when given a relative path. No it doesn't. Relative links work fine --- cmd /c dir reports them as relative, anyway. This means the link will point at the wrong thing if it's moved about. I don't know whether native relative links are possible. They are possible, and at least in my testing, they work fine. A relative symbolic link should be created whenever cygpath -w returns a relative path. (Some of these points rule out the use of native symbolic links as Cygwin symbolic links.) And that's a shame. Windows symbolic links are tantalizingly close to POSIX links, but not quite there. [1] I wonder why Windows uses these security rights things instead of just using a normal group for each privilege under "User Rights Assignment", each with a well-known SID. That'd have reduced the number of moving parts in the system. -- 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
Better perl rebase solutions
For the upcoming perl-5.14.0 update I'm toying with this idea.
Problem:
Forked perl's with new XS dll's very often fail because of imagebase
clashes. The current solution is perlrebase when such an error appears.
We want to automatize perlrebase whenever you install a new XS extension
(via cpan).
But even when testing the new XS dll in blib/arch we might get imagebase
clashes.
Idea:
Use a global $vendorarch/auto/.rebase file which stores the next
available imagebase for the next to be built perl XS dll.
perlrebase also writes to this file.
I'll ship a new initial $vendorarch/auto/.rebase file.
perlrebase will add:
...
/usr/bin/rebase -v -b $baseaddr -T rebase$suff.lst | /usr/bin/tee $full
stat=$?
echo $stat
[ -n $stat ] || exit
[ -e /usr/bin/peflags.exe ] && /usr/bin/grep .dll rebase$suff.lst |
/usr/bin/peflags -d0 -T - >/dev/null
/usr/bin/cat rebase$suff.lst | /usr/bin/xargs chmod g-w
/usr/bin/tail -n1 $full | \
$perl -ne'/new base = (.+), new size = (.+)/ &&
printf("%x\n",hex($1)+hex($2));' \
> /usr/lib/perl5/vendor_perl/$ver/$arch/auto/.rebase
/bin/cat /usr/lib/perl5/vendor_perl/$ver/$arch/auto/.rebase
ExtUtils::MakeMaker will use this new snippet:
=item dynamic_lib
Use the default to produce the *.dll's.
Add the dll size to F<$vendorarch/auto/.rebase>, which stores the
next available imagebase.
If an old dll exists and .rebase is empty, use the same rebase address
for new archdir dll's.
=cut
sub dynamic_lib {
my($self, %attribs) = @_;
my $s = ExtUtils::MM_Unix::dynamic_lib($self, %attribs);
my $ori =
"$self->{INSTALLARCHLIB}/auto/$self->{FULLEXT}/$self->{BASEEXT}.$self->{DLEXT}";
my $rebase = "$self->{INSTALLVENDORARCH}/auto/.rebase";
my $imagebase;
if (-f $rebase) {
$imagebase = `/bin/cat $rebase`;
chomp $imagebase;
}
if (!$imagebase and -e $ori) {
$imagebase = `/bin/objdump -p $ori | /bin/grep ImageBase |
/bin/cut -c12-`;
chomp $imagebase;
if ($imagebase gt "4000" and $imagebase lt "8000") {
my $LDDLFLAGS = $self->{LDDLFLAGS};
$LDDLFLAGS =~
s/-Wl,--enable-auto-image-base/-Wl,--image-base=0x$imagebase/;
$s =~ s/ \$\(LDDLFLAGS\) / $LDDLFLAGS /m;
}
} elsif ($imagebase gt "4000" and $imagebase lt "8000") {
my $LDDLFLAGS = $self->{LDDLFLAGS};
$LDDLFLAGS =~
s/-Wl,--enable-auto-image-base/-Wl,--image-base=0x$imagebase/ or
$LDDLFLAGS .= " -Wl,--image-base=0x$imagebase";
$s =~ s/ \$\(LDDLFLAGS\) / $LDDLFLAGS /m;
# Need a tempfile, because gmake expands $_ in the perl cmdline
open F, ">", "_rebase.pl";
print F qq(/new base = (.+), new size = (.+)/ &&
printf("%x\\n",hex(\$1)+hex(\$2)););
close F;
# TODO Here we create all DLL's per project with the same
imagebase. We'd need
# a better tool to inc the imagebase.
$s .= "\t/bin/rebase -v -b 0x$imagebase \$@ | ";
$s .= "\$(FULLPERL) -n _rebase.pl >
\$(INSTALLVENDORARCH)/auto/.rebase\n";
} else {
warn "Hint: run perlrebase to initialize $rebase\n";
}
$s;
}
The above snippet creates a GNU makefile rule how to build DLLs.
This works but has two problems:
1. There might be nameclashes with an existing _rebase.pl file in a CPAN
module (very unlikely).
I started with a cmdline, like
$s .= "\t/bin/rebase -v -b 0x$imagebase \$@ | ";
$s .= "\$(FULLPERL) -ne'/new size = (.+)/ &&
printf(\"%x\\n\",hex(\$imagebase)+hex(\$1));)' >
\$(INSTALLVENDORARCH)/auto/.rebase\n";
But I cannot solve the hex(\$1) problem. GNU make always expands $_ to
/usr/bin/make and I cannot quote that make expansion. And I need to pass
$_ to perl and I cannot use overlong makefile lines.
People are also using different shells. So we need to use a tempfile.
-MFile::Temp is also pretty long.
2. Multiple XS extensions per CPAN package will be created with the same
imagebase. In order to check each new imagebase at run-time we'd need a
better tool to increment the imagebase, which can be called from within
gmake. Should I write such a beast also? But just for perl?
If so setup.exe could be extended to rebase new dlls automatically.
Code-sharing.
python has the same problem, and we didn't even start with ruby.
3. The imagebase of already existing XS dll's are not reused. It is only
shrinked with the next perlrebase.
perl-5.14.0 is now at 5b32 with 74 installed extensions (typical),
with perl5.12.2 I was at 57f4 with 94 installed extensions (medium),
with perl-5.10.1 at 5a3b with 222 installed extensions (many).
perl can only use 0x5700 - 0x6?00.
Downwards we are limited by the active Windows system dll's, upwards by
the latest rebaseall imagebase, which goes from 0x7000 downwards.
5b32 is a lot compared to 5a3b and we will run out of space
soon. I already removed all CPAN::Reporter dependencies
but the new DLL's seem to be just bigger.
--
Reini Urban
http://phpwiki.org/ http://murbreak
listen socket / poll block
Hello,
I made a small application that block poll function.
the result is :
before pthread_create
after pthread_create
before poll
before shutdown socket
after shutdown socket
before close socket
after close socket
under linux the result is:
before pthread_create
after pthread_create
before poll
before shutdown socket
after shutdown socket
after poll ret=1
error accept failed: Invalid argument
The code of my application are :
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int SocketFD;
void * my_thread(void* arg)
{
struct sockaddr_in stSockAddr;
int ret;
struct pollfd p;
SocketFD = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
if(-1 == SocketFD)
{
perror("can not create socket");
exit(EXIT_FAILURE);
}
memset(&stSockAddr, 0, sizeof(stSockAddr));
stSockAddr.sin_family = AF_INET;
stSockAddr.sin_port = htons(1100);
stSockAddr.sin_addr.s_addr = INADDR_ANY;
if(-1 == bind(SocketFD, (struct sockaddr *)&stSockAddr, sizeof(stSockAddr)))
{
perror("error bind failed");
close(SocketFD);
exit(EXIT_FAILURE);
}
if(-1 == listen(SocketFD, 10))
{
perror("error listen failed");
close(SocketFD);
exit(EXIT_FAILURE);
}
for(;;)
{
memset (&p, 0, sizeof (p));
p.fd = SocketFD;
p.events = POLLIN;
p.revents = 0;
printf("before poll\n");
ret = poll (&p, 1, -1);
printf("after poll ret=%d\n", ret);
int ConnectFD = accept(SocketFD, NULL, NULL);
if(0 > ConnectFD)
{
perror("error accept failed");
close(SocketFD);
exit(EXIT_FAILURE);
}
/* perform read write operations ...
read(sockfd,buff,size)*/
shutdown(ConnectFD, SHUT_RDWR);
close(ConnectFD);
}
close(SocketFD);
return 0;
}
int main(void)
{
pthread_t id;
printf("before pthread_create\n");
pthread_create(&id, NULL, my_thread, NULL);
printf("after pthread_create\n");
sleep(3);
printf("before shutdown socket\n");
shutdown(SocketFD,2);
printf("after shutdown socket\n");
sleep(3);
printf("before close socket\n");
close(SocketFD);
printf("after close socket\n");
sleep(30);
}
--
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: octave updated to 3.4.0-3. Please test (strcat error)
On Wed, Apr 06, 2011 at 03:54:05PM +0900, Tatsuro MATSUOKA wrote: >Hello > >I have confirmed that octave-3.4.0-3 fails to plot on cygwin 1.7.9-1 but not >1.7.8-1. We don't need confirmation that octave doesn't work. We need to know if rebasing works around the problem. -- 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: .profile not sourced?
On Wed, Apr 06, 2011 at 07:16:06AM +0100, Andy Koppe wrote: > > On 4/5/2011 4:47 PM, philippe roux wrote: > >> I have a file ~/.profile which contains some alias like > >> and ./bash_profile file containing the lines When using bash as a login shell, the existence of .bash_profile prevents from .profile being sourced. Check the bash manpage for info regarding startup files. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: Utility: winln, a drop-in replacement for ln(1)
On 4 April 2011 21:30, Daniel Colascione wrote: > Attached is a small program that behaves very similarly to ln(1), but that > works with Windows hard and symbolic links instead of Cygwin ones. > Successful use of this program requires Vista or newer, a user with > SeCreateSymbolicLinkPrivilege, and a symlink evaluation policy that allows > the kind of symbolic link you'd like to create. If these conditions are > met, however, this program becomes useful because it can create symbolic > links that work equally well for Cygwin and non-Cygwin programs. Because > its argument handling is practically identical to that of coreutils ln, > winln can be used via a simple shell alias (or PATH prefixing, if you're > feeling bold). Very nice, and much better than faffing about with 'cmd /c mklink' and cygpath. A few points of note: - Coretools ln also creates native Windows hard links, via Cygwin's link() function. - Cygwin link() directly invokes the NT API, which I think avoids some filename restrictions at the Win32 level. - winln doesn't have the .exe magic where links to .exes automatically have .exe appended if it's not already present. - Native symbolic links require administrator privileges and aren't available at all before Vista. - 'cmd /c mklink /j' allows to create directory junction points without administrator privileges. Junction points are more or less equivalent with symbolic links, and the 'linkd' utility from the Windows Reource Kit Tools even allows to create them on XP. Hence it might be useful for winln to fall back to junction points when symbolic links aren't available. - Native symbolic links obviously point at Windows paths, which means they end up pointing at the wrong thing if the meaning of their original POSIX path changes, in particular due to changing mount points or Cygwin symlinks in the original path. - 'winln' always creates a link to the absolute Windows path when given a relative path. This means the link will point at the wrong thing if it's moved about. I don't know whether native relative links are possible. (Some of these points rule out the use of native symbolic links as Cygwin symbolic links.) 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: .profile not sourced?
Le 06/04/2011 00:01, Larry Hall (Cygwin) a écrit : Do what cygwin.bat does - invoke bash as a login shell: run mintty -e /bin/bash --login -i thank you for all explanations, Philippe -- 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
