Re: base-files-4.1-2
On Fri, Jul 05, 2013 at 02:09:44PM +0200, Corinna Vinschen wrote: On Jul 5 07:33, Ken Brown wrote: base-files-4.1-2 was released as a test version in March 2012. Is there a plan to promote it to current? I'm not aware of any problems with it. I just tried it on 64 bit, and I see some problems. - /etc/postinstall/base-files-mketc.sh Only cosmetically: The dos file warning when creating the service files is annoying. Setting CYGWIN=nodosfilewarning might be a good idea. - /etc/profile.d/1777fix.sh Calls getfacl without path. Assuming tcsh is your login shell, at the time this is run under tcsh, there's no default PATH set, so the script doesn't find the tools: /etc/profile.d/1777fix.sh: line 36: getfacl: command not found /etc/profile.d/1777fix.sh: line 36: getfacl: command not found /etc/profile.d/1777fix.sh: line 36: getfacl: command not found /etc/profile.d/1777fix.sh: line 36: getfacl: command not found /etc/profile.d/1777fix.sh: line 36: getfacl: command not found /etc/profile.d/1777fix.sh: line 46: touch: command not found Using the full path for all tools would fix that. Other than that it's ok I think. Sorry for the late response. I'll fix this and send an RFU for 4.2 during this weekend. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Creating CD of installation packages: Download incomplete. Try again?
On Sat, Nov 24, 2012 at 07:31:48PM +, Paul wrote: Robert Pendell shinji+cygwin at elite-systems.org writes: Also, I was wondering if cygwin comes with release notes. I wasn't able to find any in the search described in my last post. http://cygwin.com/cygwin-ug-net/ov-new1.7.html -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Passwordless authentication between two domains.
On Tue, Nov 20, 2012 at 10:16:12AM -0800, Andrew DeFaria wrote: On 11/20/2012 9:46 AM, anulav2 wrote: Permissons on .ssh are 700 and .ssh/authorized_keys are 600. I have tried uninstall and re-install twice. and following is part of what i get when i increase verbosity. Is your home directory, oddly named /home/pal.rsync, set to 755? How about ~/.ssh? Also 755. No. 700. That may be the problem. My ~/.ssh/authorized_keys is set to 644. My ~/.ssh/id_rsa is 600 but ~/.ssh/id_rsa.pub is 644. I think it is advisable to chmod go= -R the whole ~/.ssh directory and also enable the StrictModes directive in sshd_config, amongst several other good practices WRT to sshd. Permissions of your $HOME directory are also relevant. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: (base-files 4.1-2) Typos in Default Home Directory Files
On Thu, Nov 08, 2012 at 11:12:59PM -0600, Ethan Warth wrote: I send this to report a comment typo in the the skeleton files automatically added to home folders (package base-files was updated to version 4.1-2 to verify the typos were still in the newest release). 1901/4086 MB RAM 0.00 0.00 0.00 2/7 Thu Nov 08 11:00:55 11:00 PM [0 jobs] [ethan@firetail: +1] /etc/defaults/etc/skel $ grep -rn benifitial . ./.bashrc:21:# would be benifitial to all, please feel free to send ./.bash_profile:21:# would be benifitial to all, please feel free to send ./.inputrc:21:# would be benifitial to all, please feel free to send 1896/4086 MB RAM 0.00 0.00 0.00 1/8 Thu Nov 08 11:01:09 11:01 PM [0 jobs] [ethan@firetail: +1] /etc/defaults/etc/skel $ grep -rn benificial . ./.profile:21:# would be benificial to all, please feel free to send The correct spelling is be beneficial. Thanks for the report. It has already been corrected and will be available in the next release of base files. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: LICENSE: base-files and use of CC0 - public domain
On Fri, Oct 26, 2012 at 12:26:59PM -0600, Warren Young wrote: On 10/25/2012 11:49 AM, Jari Aalto wrote: Neither OSI, nor FSF recommend use of public domain for Open Source software. I think you should total up the list of recommendations the FSF has made over the years, and decide if you really want to be constrained use only things that make FSF happy. FSF recommends use of existing licences (GNU licences, Apache ...), likewise OSI: We recommend that you always apply an approved Open Source license to software you are releasing, rather than try to waive copyright [= put into public domain] altogether. http://opensource.org/faq#public-domain CC0 is a bit more complicated than pure public domain. ... This “Give-It-Away” license provides no protection for anyone if the donated software causes harm (...) one [cannot] escape a lawsuit just because his gift was only accidentally harmful. CC0 contains a warranty disclaimer. (§4.b.) If utmost free were the initial intention -- What was wrong with the BSD[1] or MIT licenses, which are desinged to be Open Source software licenses? My point is that this is basically what you get, when you live somewhere that doesn't allow public domain copyright disclaimer. When I first decided to use CC0, I admitedly didn't do too much of a research. I concur with Corinna that the contents of the base-files package is simple enough not to even worry about licensing, but as concern about this reached the list[1], I simply looked for something a little bit more serious than the beer-ware[2] license and used it: I found the CC0 to be FSF[3] approved, and I thought it was an authoritative enough source of information. I really don't mind to move to any of BSD-2 or GPLv3 if needed, but I definitely don't want to see my name in each and every one of the files, because I'm only the mantainer here, and most of the code was already there or has been contributed by others, so before I merge those kindly sent pull-requests, I'd like to know if the copyright attribution in the headers could reference the cygwin project, something like: ( Copyright (c) 2010-2012 The cygwin project http://cygwin.com ) That would be both fair and accurate. Thanks for any pointers. [1] Sorry, didn't find it in the archives, look for it around October 2011 [2] https://en.wikipedia.org/wiki/Beerware [3] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses https://www.gnu.org/licenses/license-list.html#CC0 -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: LICENSE: base-files and use of CC0 - public domain
https://github.com/dsastrem/base-files.git
Most probably, a wrong assumption on my side.
I am not a lawyer, and most of this parlance goes far beyond my
understanding. I wouldn't mean any harm whatsoever to this project, or
would I purposedly introduced a legal flaw by using the Public Domain
License in the base-files package contents.
What would be more appropriate? GPLv3?
On other news, I'm frankly short of time to dedicate to base-files
mantainership. It has a long time pending promotion from test to
current. The aforementioned github repo is available to anyone who
would like to adopt it, as well as the packages from cygwin.com, of
course. The only outstanding issue I can think of right now, would be
to revert this change:
-PATH=/usr/local/bin:/usr/bin:${PATH}
+ORIGINAL_PATH=${PATH}
+PATH=/usr/local/bin:/usr/bin
The details about this issue can be found here:
http://cygwin.com/ml/cygwin/2012-08/msg00488.html
I'm still actively monitoring the cygwin list, so I'll try to respond
promptly to any comments or suggestions regarding this question.
--
Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: RFU: keychain 2.7.1-1 (ITA: new maintainer)
On Wed, Oct 10, 2012 at 11:00:04AM +0200, Corinna Vinschen wrote: On Oct 10 08:44, Jari Aalto wrote: 2012-10-09 21:49 David Sastre Medina | | P.S. keychain (also a simple shell script) is orphaned, and there's a | new version upstream, just in case you're interested. New upstream release: Err... hang on. This package is officially maintained by Jonathan C. Allen. I admit that we had no feedback from him since 2007, but it doesn't hurt to ask. Jonathan? Are you still with us in some way? You are still officially maintainer of 5 packages, bsflite, keychain, naim, ncftp and tnef. None of them has been update since 2007, though... I'm sorry. Somehow, I had the idea of keychain being orphaned already. I tried searching the mail archives, but I could only find this thread from some months ago: http://sourceware.org/ml/cygwin-apps/2012-03/msg00082.html Again, I apologize. Completely unintended. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: ITP: makeself -- Utility to generate self-extractable archives
On Mon, Oct 08, 2012 at 04:02:30PM +0300, Jari Aalto wrote: 2012-10-08 07:41 Steven Monai: | makeself is already in the Cygwin archive. Ok, good. Jari, If you want to take over mantainership of makeself, I have no objections. According to its git log, there have been some minor improvements during this year. P.S. keychain (also a simple shell script) is orphaned, and there's a new version upstream, just in case you're interested. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Attn: base-files maintainer? [Was: sshd from user account - env issues]
On Tue, Sep 25, 2012 at 01:18:57PM -0700, jafa wrote: On 9/19/2012 10:45 PM, Charles Wilson wrote: On 9/19/2012 1:41 PM, jafa wrote: Try installing the test version of the base-files package (4.1-2). There was a thread six months ago or so where it was decided that setting vars in both upcase and lowercase was a bad idea (breaks .net applications, for one thing, and confuses many others). This change was implemented in base-files as a test, but has never been promoted. Nor did I had the smallest piece of feedback :( Chuck, thanks for the wake up call. I'll try releasing a new one during the next week. Windows sets temp and tmp to windows style paths (eg C:\Users\build\AppData\Local\Temp) Cygwin sets TEMP and TMP to cygwin style paths (eg /tmp) Confirming, MSVS fails to compile if both TMP and tmp are set. The workaround is to unset TEMP and TMP on the line that invokes MSVS. MSVS detects the Windows style temp and tmp vars and runs ok. Having just one TMP var may cause problems... if TMP is set to a cygwin style path MSVS won't work, and if TMP is set to a Windows style path some cygwin apps might not work. The current release implementation works ok - Cygwin apps work without issue and MSVS works as long as you unset TEMP and TMP before invoking. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: /etc/profile
On Tue, Aug 21, 2012 at 10:16:28AM +, Achim Gratz wrote: I'm removing the Windows PATH in my startup scripts since there's nothing in there that I think should be accessible from Cygwin. For (t)csh this is easy enough to do with dropping a script into /etc/profile.d that gets executed first, but there's no such provision for sh and the ilk since PATH is set up already before it get there. Now, unless profile gets changed I can still cut off /usr/local/bin:/usr/bin: with a profile.d script, but I think it might be preferrable that the Windows path gets recorded into ORIGINAL_PATH or some similar name at the beginning of profile. It would then be a simple matter to later add the Windows path where appropriate, but I don't think the default path should have it at all. Also, there are two things in profile that may admit slight improvement (a place where LC_COLLATE is specified just for one command and better guarding against a missing or non-cdable /etc/skel). All three changes will be available in the next release (profile_d modification taken from your last version in this thread). Thanks. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: /etc/profile
On Wed, Aug 22, 2012 at 09:15:58PM +0200, Achim Gratz wrote: If you'd rather have a complete patch, let me know and I'll post it or send it to you via email, as you prefer. I'm having this on github now for easier handling. Check https://github.com/dsastrem/base-files.git -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: /etc/profile
On Wed, Aug 22, 2012 at 01:13:37PM -0700, Daniel Colascione wrote:
On 8/22/12 12:10 PM, David Sastre Medina wrote:
On Tue, Aug 21, 2012 at 10:16:28AM +, Achim Gratz wrote:
I'm removing the Windows PATH in my startup scripts since there's nothing
in
there that I think should be accessible from Cygwin.
All three changes will be available in the next release (profile_d
modification taken from your last version in this thread).
Are you sure that's actually a good idea? I don't agree with this logic:
People execute Windows programs using Cygwin all the time. With this
change, basic things like cmd and notepad will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.
I for one never start windows programs from within a shell, with the
exception of firefox, and for that I registered an entry in the
alternatives system (x-www-browser), however, I take your advice and
I'll give this a second thought, and also would like to hear from
others' opnion wrt to this.
Obviously, ORIGINAL_PATH (as proposed in Achim's patch) would
still hold the native Windows' PATH, so it'd be very easy to include a
(commented?) line using it, so it would be easy to switch it:
#PATH=/usr/local/bin:/usr/bin:${ORIGINAL_PATH}
--
Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: /etc/profile
On Wed, Aug 22, 2012 at 05:18:31PM -0400, Christopher Faylor wrote: I'll just reiterate what Daniel said again: We can't make things like cmd or notepad stop working. That would be a disaster. I wasn't really following the discussion, and don't really want to check stuff out in git to see what's going on, but if the proposed change just makes it possible for purists to remove the Windows PATH from the Cygwin one however that's great. Otherwise, removing the Windows path entirely really won't please very many people. ACK. I'll keep PATH untouched and see if there are other ways to offer this functionality as an option. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: internal-sftp logs
On Fri, Aug 17, 2012 at 01:46:42PM -0400, James Calfee wrote:
Where are the logs in Cygwin for sftp?
I'm using the sftp subsystem. There is nothing to be found in
/var/log/sshd.log or /var/log/*. I have already enabled logging in my
sshd_config file as follows:
Subsystem sftpinternal-sftp -l INFO
Just define the subsystem and configure the SyslogFacility option
to suit your needs, which in turn depends on how you've configured
your syslog daemon. E.g. :
sshd_config:
Subsystem sftpinternal-sftp
SyslogFacility AUTH
syslog-ng.conf:
source s_src { system(); internal(); };
destination d_auth { file(/var/log/auth.log); };
filter f_auth { facility(auth, authpriv) and not filter(f_debug); };
log { source(s_src); filter(f_auth); destination(d_auth); };
--
Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: Installing Cygwin C and C++ compilers for NetBeans IDE 7.2
On Sat, Jul 28, 2012 at 06:06:16AM -0700, nososo wrote: The installation took up a long time so i stopped after about 45 minutes or so. I'd be surprised if something worked properly after having interrupted the installation process. Try reinstalling, let the process end its job this time, and after that, follow the guidelines described here to report a problem: http://cygwin.com/problems.html -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: FAQ and Documentation translation to other languages
On Sun, Jul 22, 2012 at 10:58:18PM +0200, SPC wrote: On the comments of Andrey, I've started with the translation into Spanish (from Spain) this afternoon. I have used the Google translator for a first translation and then review the results in detail. In this case the translation to Spanish provided by Google was acceptable. Of course, I didn't front yet the body of the FAQ :-) If would be nice if you could share a link to your work. I'll be glad to review your translation if you like the idea. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Fwd: FAQ and Documentation translation to other languages
On Tue, Jul 24, 2012 at 10:35:10PM +0200, SPC wrote: No problem. But let me organize myself :-) But, one questión... Some preferences to stablish a repository ? I have account in Git, Sourceforge and Google for diverse projects, and I could use one Project Site as ProjectLinkr or Teambox if needed. In the most simple case, I could define a resource and store the work under a Public Directory in Dropbox, Box.net or similar services. Preferences ? GitHub is fine for me, but I'll use whichever one you prefer. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: FAQ and Documentation translation to other languages
On Sat, Jul 21, 2012 at 12:18:01PM -0400, Buchbinder, Barry (NIH/NIAID) [E] wrote: Spanish: http://translate.google.com/translate?sl=enjs=nprev=_thl=enie=UTF-8layout=2eotf=1u=http%3A%2F%2Fcygwin.com%2Ffaq.htmlact=urltl=es Please don't use this translation, 50% of it doesn't make any sense at all. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: FAQ and Documentation translation to other languages
On Sat, Jul 21, 2012 at 07:38:15PM +0200, SPC wrote: snip about the translation from other idioms to Spanish. I wondered about s/idiom/language/ -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: perlcritic perltidy
On Fri, Jul 06, 2012 at 05:23:00PM -0700, Andrew DeFaria wrote: Not specifically a Cygwin question but I used to be able to do cpan perlcritic or cpan perltidy to install those. But now when I try I get: Warning: Cannot install perlcritic, don't know what it is. Try the command i /perlcritic/ to find objects with matching identifiers. I tried the i /perlcritic/ and no package seems to be the right one: cpan[1] i /perlcritic/ CPAN: Storable loaded ok (v2.20) Reading '/home/adefaria/.cpan/Metadata' Database was generated on Fri, 06 Jul 2012 01:43:03 GMT DistributionAZAWAWI/Padre-Plugin-PerlCritic-0.12.tar.gz Module Benchmark::Perl::Formance::Plugin::PerlCritic (SCHWIGON/perl-formance/Benchmark-Perl-Formance-0.27.tar.gz) Module Code::TidyAll::Plugin::PerlCritic (JSWARTZ/Code-TidyAll-0.02.tar.gz) Module Padre::Plugin::PerlCritic (AZAWAWI/Padre-Plugin-PerlCritic-0.12.tar.gz) Module Test::Apocalypse::PerlCritic (APOCAL/Test-Apocalypse-1.002.tar.gz) 5 items found cpan[2] Any ideas? Maybe m /^perl::tidy$/ m /^perl::critic$/ HTH -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Why won't my .sh file work with cygwin?
Completely unrelated to your script problem but you should definitely take a look at pwgen (there's a cygwin package). -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Windows Guest Account Locked SSH
On Wed, Jun 27, 2012 at 12:13:25PM +, George Luiz Bittencourt wrote: We are running a very old version, Cygwin 1.5.2, but we are not sure if this is the cause. You should update (probably reinstalling would be better) to current cygwin if possible, and check if you still have the same problem. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: installing rsyncd
On Tue, Jun 05, 2012 at 12:47:38PM -0500, carolus wrote: The Cygwin README for rsync says: 2) to install service: (cygrunsrv --help for help) cygrunsrv -I rsyncd -p /usr/bin/rsync -a '--daemon --no-detach' This command seems to run OK with no messages, but then ps does not show rsyncd or rsync. This is because the above command only installs the service. You should be able to query its state using: cygrunsrv -Q rsyncd And start it with: cygrunsrv -S rsyncd Also, it should be there if you check in mmc - services though the Windows native facilities. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [feature] alias more to less
On Tue, May 15, 2012 at 08:39:22AM -0700, Andrew DeFaria wrote: On 05/11/2012 01:33 AM, Noel Grandin wrote: It seems that pretty much all unixes alias more to less these days. It would be very nice if that was the default behaviour of cygwin. I second this! Granted I know how to alias more to less and I do so for my environment. But I'm often working in or helping others in Cygwin in their environment and most people, let's face it, have no environment and fear the command line so! Or, as is the current case with my client, have a generic user that is used for things like building and we go about setting up Cygwin on multiple build machines but we end up with plain installs with no environment and no aliasing of more - less. Having to run around to groups of machines further configuring things like these often used aliases is a pain. And every time a new build machine is spun up and Cygwin installed (via a .cmd file I cooked up) the alias is missing on that new machine. It would be nice if this alias was a default for Cygwin. (Yes I know I can change my package to do customizations after installing Cygwin but I have not yet had the time to further enhance my Cygwin Install package...) I understand some people expect less when they type more. There are other pagers as well: w3m, most, pg (some of them not available in cygwin, though). I use my own home-brewed most pager all the time, for instance. No alias is enforced from config files (note also that this affects only bash), so you'd have to tweak some file anyways in order to have that alias as a default on your automated installations. I think it would be way better if pagers registered themselves (via postinstallation script) in the alternatives system. That way, only an 'alternatives --config pager' command would suffice to fullfil your purpose. This, of course, results in a system-wide configuration, but that's what you seem to be looking for. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: installing rsh and rlogin servers - rshd and rlogind
On Sun, May 13, 2012 at 11:29:52AM +0100, Marilo wrote: I know ssh is the recommended thing, it has encryption and public keys. But I would like to install and try rsh and the like nonetheless to see what it was like. I'm the only person on my LAN and it's just for my LAN. I would like to use rsh and rlogin, and their respective servers I can see the rsh and rlogin commands, but not their servers. There is a package called rsh-server, but i've looked for the file rsh-server and not found it, and I see no packages mentioning rshd or rlogind or telnetd and I don't see those files on my system. http://cygwin.com/cgi-bin2/package-cat.cgi?file=rsh-server%2Frsh-server-0.17-1grep=rshd http://cygwin.com/cgi-bin2/package-cat.cgi?file=rsh-server%2Frsh-server-0.17-1grep=rlogind and check the output of $ cygcheck -l rsh-server -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: 1.7.14-2: bash not accepting ~ (tilde) from keyboard in Console (WIN7)
On Fri, May 04, 2012 at 11:43:23PM +0200, Chris Brouwer wrote: I have just installed Cygwin 1.17.14-2 using the setup.exe. I use Console (portable; from Portableapp.Com) as my entry to bash. I have tried this when calling cygwin.bat from Explorer, effectively starting cygwin from cmd.exe, and then the ~ works as expected. Does anyone have a solution for this ? Yes. Just use mintty. It's the default and it works. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Why /usr/bin/*.dll must be executable?
On Mon, Apr 23, 2012 at 01:02:39PM -0600, Warren Young wrote: On 4/20/2012 1:06 PM, Jon TURNEY wrote: 'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't want to see those pesky dlls. Is there a good reason this isn't in the stock /etc/bash.bashrc? Not that I can think of. Added for the next release of base-files. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: svn and Tortoise
On Fri, Apr 13, 2012 at 03:13:54PM +1000, Rurik Christiansen wrote: Funnily enough there is no bash.bashrc or global profile or such (unlike for csh) You should have /etc/profile and /etc/bash.bashrc. They are part of base-files. Try 'cygcheck -l base-files'. If you don't have them in place, there should be a copy under /etc/defaults. Otherwise, reinstall base-files. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: gem remap problem
On Thu, Apr 12, 2012 at 11:02:30AM +0200, Neusbeer wrote: Since a few weeks when I try to install a gem I get a remap error. I tried rebasing with ash /bin/rebaseall -v but nothing works :( I get the following error: example-cut: gem install pcaprub Building native extensions. This could take a while... 190 [main] ruby 3172 child_info_fork::abort: unable to remap zlib.so to same address as parent (0495) - try running rebaseall 57 [main] ruby 2784 child_info_fork::abort: unable to remap Win32API.so to same address as parent (048F) - try running rebase all 3 [main] ruby 3052 child_info_fork::abort: unable to remap zlib.so to same address as parent (0495) - try running rebaseall ERROR: Interrupted It appears only with zlib and win32api. Since you don't specify which cygwin version are you using, the first suggestion would be to update to the latest, or even try a snapshot from http://cygwin.com/snapshots. There have been many and significant improvements in this area, so that might help. If that is not the case, everybody here will want to take a look at the standard problem report: Problem reports: http://cygwin.com/problems.html -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: sshd not doing key based authentication
(replying to the list, sorry if it breaks the thread) On Thu, Apr 05, 2012 at 03:19:41PM +1000, Rurik Christiansen wrote: I was hoping more for some pointers to what the permissions must be and then do the troubleshooting myself. The unix side of permissions look ok. I don't know what the windows side must be or if it matters. The ssh -vvv' (client side) has not been particularly helpful to me when it comes to permissions. and my understanding is that I can't run the sshd frontend without screwing the permissions. (the client sends the publickey packet and then jumps to next auth method) How did you setup the server? IIRC, ssh-host-config complains if it finds wrong perms. How do you start the service? Is there something in /var/log/sshd.log (provided you are logging there, and not elsewhere via syslog-ng or other means). You could also delete the service and recreate it. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: sshd not doing key based authentication
On Wed, Apr 04, 2012 at 03:26:39PM +0400, Andrey Repin wrote: Greetings, Rurik Christiansen! I'm trying to make sshd to do key based authentication. I am guessing that is probably a problem of permissions but can't figure it out. All I found was this email: http://cygwin.com/ml/cygwin/2008-11/msg00212.html which basically says RTFM Well, I did RTFM, I followed the instructions. all looks OK as far as I can see but still no go. Read logs on both sides, of course. The most common issue is access rights on key files. Check for PubkeyAuthentication, StrictModes, AllowUsers, AllowGroups, AuthorizedKeysFile in the server side (whether they exist and how they are defined), read the manpage for detailed info on this options (sshd_config(5)). Try setting LogLevel to DEBUG. Provide a 'ssh -vvv user@host' test connection. You don't give enough info to figure out what the problem might be. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Proposed change to base-files /etc/bash.bashrc: see whether PS1 has already been set
On Mon, Mar 26, 2012 at 04:40:31PM +0100, David Caldwell wrote: I can't figure out where the CVS is for base-files, but I wanted to propose that the file: /etc/bash.bashrc ... be altered to test whether the PS1 variable has already been set before setting it to the default. I set mine in a file in the /etc/profile.d directory, but with the standard Cygwin installation, this value is overwritten unless I modify each user's local setup or alter the system-wide file. It would be harmless to ignore already-set values in this situation. I could obviously generate a patch as necessary if I knew where the repository was, but it's a one-liner, basically: if [ -z $PS1 ]; then PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' fi There is no public repository for the package. That does not stop you from generating a patch, though :) You forgot to say which shell are you using, as they are/can be differently set up WRT PS1. If I wanted all my users to get a custom (read: different from the default) PS1, I guess I'd use the skel files for that. If you decide to use a custom /etc/profile.d/ script to do that job, then you need to tweak system-wide /etc/profile as well, IMHO. Also, the patch is indeed harmless, but, as you provide it, i needs to be used once for each ifdef in the profile. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Proposed change to base-files /etc/bash.bashrc: see whether PS1 has already been set
On Mon, Mar 26, 2012 at 09:12:11PM +0100, David Caldwell wrote: On Mon, Mar 26 2012 at 09:22:3147PM +0200, David Sastre Medina wrote: On Mon, Mar 26, 2012 at 04:40:31PM +0100, David Caldwell wrote: I can't figure out where the CVS is for base-files, but I wanted to propose that the file: /etc/bash.bashrc Oops! So sorry. I (obviously) overlooked this line... I'm not sure why one would need to alter /etc/profile to create an /etc/profile.d script, but I'm open to hearing more. What I tried to say is that by adding a custom /etc/profile.d/ script, you are overriding the default setup for bash, and therefore it would not be that weird to alter also /etc/profile. I never implied that by adding the former one would be forced to alter the latter. I suppose an alternative, equivalent change to the one I originally proposed might be to execute /etc/bash.bashrc *before* executing the files in /etc/profile.d; either makes sense to me. I'm not sure what the precedence order of those ought to be but my view is bash.bashrc ought to be executed first as it is providing out-of-the-box defaults and /etc/profile.d is intended for local modification. I see what you mean. It looks a much simpler solution to swap those lines. I'll check it doesn't (unexpectedly) break anything else and add it for the next release. Thanks. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Can't find program in my path
On Thu, Mar 15, 2012 at 08:25:40PM -0600, Jim Reisert AD1C wrote: I can't find a particular application in my path. It used to work, but I haven't run this application since the last couple of Cygwin releases. path(. /cygdrive/d/Home/bin /usr/local/emacs/bin /usr/local/bin /usr/bin /cygdrive/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common /cygdrive/d/Perl/site/bin /cygdrive/d/Perl/bin /cygdrive/d/ActiveState Perl Dev Kit 9.1.1/bin /cygdrive/c/Windows/system32 /cygdrive/c/Windows /cygdrive/c/Windows/System32/Wbem /cygdrive/c/Windows/System32/WindowsPowerShell/v1.0 /cygdrive/c/Program Files (x86)/Common Files/Acronis/SnapAPI /cygdrive/d/utility/Diskeeper Corporation/Undelete /cygdrive/c/Program Files (x86)/QuickTime/QTSystem /cygdrive/d/utility/DISKEE~1/DISKEE~1 /cygdrive/d/WATCOM/BINNT /cygdrive/d/WATCOM/BINW /usr/bin) A simple 'echo $PATH' would be better here. # ls /cygdrive/d/ActiveState Perl Dev Kit 9.1.1/bin Please note that ActiveState Perl is not really supported here, as cygwin has its own perl. lib Perl514NH911.dll perlapp-gui.exe perlcov-perl.exe perlfb.exe perltray.exe plc-gui.exe Perl510NH911.dll Perl58NH911.dll perlcov.exe perlctrl.exe perlsvc.exe perltray-gui.exe vbsperl.exe Perl512NH911.dll perlapp.exe perlcov-gui.exe perlctrl-gui.exe perlsvc-gui.exe plc.exe JJR:~ which perlapp perlapp: Command not found. JJR:~ which perlapp.exe perlapp.exe: Command not found. perlapp is clearly in that directory. I tried some other which commands with files further into the path and they were found. You mean 'which plc' or 'which perlfb' work as expected? I even did a chmod og+rwx perlapp.exe and nothing changed. # ls -l perlapp -rwx--+ 1 SYSTEM SYSTEM 401504 Dec 9 02:01 perlapp.exe Out of curiosity, what does 'getfacl /path/to/perlapp' shows? Do the other executables in the same directory have the same permissions (both DAC and ACL)? Does 'hash perlapp' solve the issue? -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
On Mon, Mar 12, 2012 at 07:51:03PM -, James Johnston wrote: I have also noticed this issue; again it was with the XML serialization functions like Andres Martinelli originally noted. The root of the problem is that Windows environment variables are not case sensitive, while they *are* in a Unix environment. Cygwin passes an environment block with duplicate identically-named variables (if case insensitive; unique if case sensitive), and this will make some Windows programs go boom, because they assume the block is maintained in a case-insensitive manner. The big problem as I see it is that Cygwin, out-of-the-box, creates an environment block that violates a basic assumption of Windows programs - that the environment block is not case sensitive. I don't know what the solution should be, but it's not this. From /etc/profile: tmp=$(cygpath -w $ORIGINAL_TMP 2 /dev/null) temp=$(cygpath -w $ORIGINAL_TEMP 2 /dev/null) TMP=/tmp TEMP=/tmp This code is what causes the crash, by creating these duplicate (from a Windows perspective) keys. I would guess that any Windows program that tries to do case-insensitive lookups in the environment is liable to crash. At the very least, it won't necessarily give you the answer you expect (if both TEMP and temp store different values and you do a case insensitive lookup of TeMp, which is going to be returned if you don't crash?) There is a test release for base-files addressing this issue. Could you try if that solves this problem for you? -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Rsync stops inmid of synchronisation
On Mon, Mar 12, 2012 at 01:48:45PM +0100, Richard Ivarson wrote: Is there a way to increase the verbosity level of the sending rsync (aside the parameter -v which we can increase to -vv or even -vvv) ? Or could rsync print further helpful information about what it is doing right now ? Because that could help me. With -vvv rsync prints information about the files it's sending to the remote rsync, but in my case when it has rsynced for a while it suddenly stops to print and do anything, and I got no idea what is happening... Maybe overkill, but you could try to strace the process. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Problem after upgrading from 1.7.9 to 1.7.10-1 - system commands not found
On Sun, Mar 11, 2012 at 12:35:02AM +0100, Fredrik Ludvigsen wrote: I think I solved this, the files /etc/bash.bash_logout /etc/profile.d /etc/profile.d/tzset.sh /etc/profile.d/tzset.csh /etc/profile.d/lang.csh /etc/profile.d/lang.sh /etc/bash.bashrc /etc/skel/.inputrc /etc/skel/.profile /etc/skel/.bashrc /etc/skel/.bash_profile /etc/profile were all located in /etc/defaults/etc moving these to /etc solved this issue for me. Files under /etc/defaults are there for a reason: they are suppossed to be a safe fall-back reference of some config files, so IMHO, in case you don't have any of those files under /etc/, copying them (i.e. not moving them) is a better move. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: mintty scroll to bottom
On Mon, Mar 05, 2012 at 07:57:29PM +0100, Lemke, Michael SZ/HZA-ZSW wrote: On March 05, 2012 6:26 PM Ryan Johnson wrote: On 05/03/2012 5:05 AM, Lemke, Michael SZ/HZA-ZSW wrote: On March 04, 2012 12:51 PM, Corinna Vinschen wrote: On Mar 2 20:20, Andy Koppe wrote: On 2 March 2012 08:41, Corinna Vinschen wrote: On Mar 1 20:43, Andy Koppe wrote: On 29 February 2012 12:46, Lemke, Michael SZ/HZA-ZSW wrote: What is the mintty equivalent to rxvt/xterm's -si|+si Turn on/off scroll-to-bottom on TTY output inhibit; resource scrollTtyOutput has opposite effect. There's no such option. Shift+End will get you back to the current output after looking at something in the scrollback, as will any keypress that sends something to the terminal. Any chance to implement this? Automatic scroll-to-bottom is a useful feature, IMHO. I disagree. The point of being able to scroll back to earlier output is to read and perhaps copy something. When doing that, having the scrollback jump back to the bottom without the user asking for it is rather unhelpful. The Windows console does this, and I always found it really frustrating. THat's why this is an option in xterm. Every use has another idea how the terminal should behave in this regard, I guess. I'd also appreciate very much implementing that option. mintty is promoted here as a replacement for rxvt but obviously lacks a functionality I've come to depend on. My use case is a terminal window in which I don't do much but where a lot of background jobs regularly produce output. A quick glance at the window tells me the current status of those jobs. Not with mintty anymore. Same with the classic use case tail -f logfile. What you describe above sounds more like mintty allowing a visible end of output to scroll off the bottom without following it, a behavior I've never observed and which would arguably be a bug. That's not what I said. When I fire up something that produces copious output (gcc bootstrap, compile emacs, etc.) mintty scrolls to track end-of-output unless I purposefully scroll upward Right, same here. Turning on scroll-to-bottom would change that. It scrolls to bottom immediately. (in which case I'd prefer it to stay put long enough to read/copy the text rather than immediately jumping me back to end-of-output). That depends on what I am doing in such a terminal. I might have a tail -f /var/log/messages in that session on a system with low syslog activity. I want to be notified immediately if there is output and don't mind being interrupted. Once the scrollbar is set back to bottom, it again tracks end-of-output. Correct. And that's the step I want to skip. The si-option does exactly that. Am I missing something? Or do your background jobs just produce output really infrequently compared to 'make all'? In this case yes, but I also like scroll-to-bottom if there's more output. The latter is the only way I can see reading stuff from the past and scroll-to-bottom coexisting peacefully They usually won't. That’s why this should be an option and not the default. Most of the behaviour discussed in this thread can be achieved or emulated using screen (notification on activity, scroll and output logging at will, etc). Might be useful to take a look at it. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On Mon, Mar 05, 2012 at 09:37:50AM -0700, Eric Blake wrote: On 03/05/2012 07:13 AM, Nellis, Kenneth wrote: From: Corinna Vinschen Thanks for the review. Like this? If you're open to improvements, the form x=$(($x + 1)) could arguably be improved with any of the following: x=$((x + 1)) Still POSIX, and supported by /bin/sh (even where /bin/sh is dash) Duly noted. Will be included in next release. Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[ANNOUNCEMENT] [TEST] Uploaded base-files-4.1-2
Version 4.1-2 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Testers please report to the cygwin list cases where the ACL enforcement described below is not properly set. 4.1-2 * Enforce a secure ACL in /home /tmp /usr/tmp /var/log /var/run using new files /etc/profile.d/1777fix.* written by Corinna Vinschen. See cygwin.com/ml/cygwin/2012-03/msg00103.html * Setting CYG_SYS_BASHRC in bash.bashrc has no effect because it is run in a subshell environment. Reported by Christian Franke. See cygwin.com/ml/cygwin/2012-02/msg00832.html If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[TEST] Uploaded base-files-4.1-2
Version 4.1-2 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Testers please report to the cygwin list cases where the ACL enforcement described below is not properly set. 4.1-2 * Enforce a secure ACL in /home /tmp /usr/tmp /var/log /var/run using new files /etc/profile.d/1777fix.* written by Corinna Vinschen. See cygwin.com/ml/cygwin/2012-03/msg00103.html * Setting CYG_SYS_BASHRC in bash.bashrc has no effect because it is run in a subshell environment. Reported by Christian Franke. See cygwin.com/ml/cygwin/2012-02/msg00832.html If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[RFU] base-files-4.1-2
Hello, Please upload base-files-4.1-2. I'd like to release 4.1-2 as a test release, so setup.hint has changed, too. http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2.sig http://crapsteak.org/cygwin/release/base-files/setup.hint I've left 4.1-1 as current and 4.1-2 as test. Please delete any older releases. Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On Fri, Mar 02, 2012 at 11:46:05AM +0100, Corinna Vinschen wrote: On Mar 1 11:08, Corinna Vinschen wrote: # Fix a problem introduced by older versions of setup.exe [...] David, ping? Can we add the below two files to base-files asap and remove the tmp/temp workaround, please? I'll send an RFU later today. Many thanks for your work. So sorry for the absence, huge pile of RL(TM) stuff these days :( -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [ANNOUNCEMENT] Uploaded base-files-4.1-1
On Wed, Feb 29, 2012 at 06:23:24PM -0500, Buchbinder, Barry (NIH/NIAID) [E] wrote: On 28 February 2012 19:58, David Sastre Medina wrote: /etc/profile/lang.* = /etc/profile.d/lang.* Thanks. Fixed. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files-4.1-1: Setting CYG_SYS_BASHRC in bash.bashrc has no effect
On Tue, Feb 28, 2012 at 11:23:07AM +0100, Christian Franke wrote: Setting CYG_SYS_BASHRC in bash.bashrc has no effect because it is run a (...subshell...) environment: Thanks. Applied. will be available in next release. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [PATCH] base-files-4.0.9: Change prompt if running with admin rights
On Mon, Feb 27, 2012 at 06:11:30PM +0100, Christian Franke wrote: This is an updated version of: http://cygwin.com/ml/cygwin/2011-04/msg00020.html Uses the detection method suggested here: http://cygwin.com/ml/cygwin/2011-04/msg00372.html Tested with bash, dash, mksh, posh, and zsh (with symlink /etc/zprofile - profile) on cygwin 1.7.11-1 and Win7 x64. I've revisited this idea several times, with the purpose of adding /usr/sbin to the PATH and coloring the prompt differently (red?) for admins. I'll see if I can come up with some variation on your patch that does all this. Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[ANNOUNCEMENT] Uploaded base-files-4.1-1
Version 4.1-1 of base-files has been uploaded. Base-files is a set of system configuration and setup files. 4.1-1 * Setting a system locale and a per-user locale breaks some configs and doesn't play well with mintty. Changed to a user-defined setting in /etc/profile/lang.* Reported by Peter Rosin and Andy Koppe. See cygwin.com/ml/cygwin/2012-02/msg00448.html *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
On Tue, Feb 28, 2012 at 03:17:54PM +0100, Corinna Vinschen wrote: On Feb 28 08:51, Jon Clugston wrote: Just a guess, but it does look suspiciously like the name of an environment variable. Wasn't there some discussion lately about differing case environment variables (tmp as opposed to TMP)? Dead on, thanks! The definitions of tmp and temp in /etc/profile result in a double definition of the %TMP% and %TEMP% dos variables from the .Net applications POV and it's too dumb to handle that gracefully. So the solution is, either we drop the tmp and temp definitions in /etc/profile, or old .net apps should be started only after calling `unset tmp temp' in bash. Btw., tmp and temp are not preserved this way in tcsh's profile scripts. So I'm wondering why we do it in /etc/profile. Can somebody give me a management summary? A while back (about the 3.x - 4.x changes in base-files), it was agreed to unset both TMP and TEMP and set them to /tmp. A user concerned about the security of files owned by windows native applications started within cygwin, reported that those files were created with 777 perms under /tmp, making it trivial for other users to read/copy temps files easily. The solution proposed, which I included in 4.0-7, was to set temporary dirs as they are now in /etc/profile. With regards to tcsh, and apart from /etc/profile.d/*.csh, it doesn't use any startup file in base-files, as you know it has its own set of /etc/csh.login /etc/csh.cshrc and a couple of files under /etc/profile.d (as of 6.18.00-3). So it is not easy for me to propagate this to tcsh. Regardless, it's probably my fault not having publicised enough that change to give tcsh, and probably zsh and mksh (both can use /etc/their-own-startup-profile) mantainers at least the chance to include it or complain. If this setting is to be dropped, we'll go back to creating unsecure files in /tmp under the described scenario (unless some other solution is implemented). -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Uploaded base-files-4.1-1
Version 4.1-1 of base-files has been uploaded. Base-files is a set of system configuration and setup files. 4.1-1 * Setting a system locale and a per-user locale breaks some configs and doesn't play well with mintty. Changed to a user-defined setting in /etc/profile/lang.* Reported by Peter Rosin and Andy Koppe. See cygwin.com/ml/cygwin/2012-02/msg00448.html *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[RFU] base-files-4.1-1
Hello, Please upload base-files-4.1-1. http://crapsteak.org/cygwin/release/base-files/base-files-4.1-1.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.1-1.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Problem after upgrading from 1.7.9 to 1.7.10-1 - system commands not found
On Mon, Feb 27, 2012 at 08:26:06PM +0100, Corinna Vinschen wrote: David, when do you plan to update the package? THe permissions are really a bad problem. Sorry. I'm requesting an RFU now. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Problem after upgrading from 1.7.9 to 1.7.10-1 - system commands not found
On Fri, Feb 24, 2012 at 03:44:46PM -0500, Bilig Ordos wrote: I've been happy with 1.7.9, but couldn't resist my curiosity so ran the 1.7.10-1 setup today. During the process it complained that Cygwin is running and offered me options to either stop the Cygwin and try again, or continue and reboot after it is done. So I selected to continue and then rebooted. But when I launched the Cywin console/Mintty, I did not have most of the system commands, such as ls and which, but commands like cd and alias are there. I tried running the setup again (made sure all the packages I used to have are selected) but did not help. rebooted again and it is the same. How can I recover from this? I hate to reinstall from scratch as doing that will make me lose a lot of customization, such as ssh keys, etc. Please see below for examples and logs. Don't panic. Your keys are still there. Also, please don't put a log into the body of the email. It's a better idea to attach it. Problem reports: http://cygwin.com/problems.html Your problem could have been caused by incorrect permissions in the latest base-files' package contents. 2012/02/24 14:33:39DownloadedC:\Users\boyun\Downloads/http%3a%2f%2fcygwin.mirrors.hoobly.com%2f/release/base-files/base-files-4.0-9.tar.bz2 2012/02/24 14:34:07Running preremove script for base-files 2012/02/24 14:34:07running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/preremove/base-files.sh 2012/02/24 14:34:10Uninstalling base-files 2012/02/24 14:34:11Extracting from file://C:\Users\boyun\Downloads/http%3a%2f%2fcygwin.mirrors.hoobly.com%2f/release/base-files/base-files-4.0-9.tar.bz2 2012/02/24 14:35:10running: C:\cygwin\bin\bash.exe --norc --noprofile/etc/postinstall/base-files-profile.sh 2012/02/24 14:35:14running: C:\cygwin\bin\bash.exe --norc --noprofile/etc/postinstall/base-files-mketc.sh Please check and correct perms if necessary in: /etc/bash.bash_logout /etc/profile.d /etc/profile.d/tzset.sh /etc/profile.d/tzset.csh /etc/profile.d/lang.csh /etc/profile.d/lang.sh /etc/bash.bashrc /etc/skel/.inputrc /etc/skel/.profile /etc/skel/.bashrc /etc/skel/.bash_profile /etc/profile All of them should have owner/group root.root and 644 perms (rw-r--r--) Afterwards, close all cygwin apps and restart a mintty session. Please report back if that solved your issue. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: hexedit install flub...now shell seems rudimentary
On Sat, Feb 18, 2012 at 07:25:37AM -0500, Ken Brown wrote: On 2/18/2012 4:20 AM, Adrian Sandstrom wrote: Would love if someone could help me get me back to my cozy Cygwin terminal. Problem: When I use the cygwin shortcuts to cygwin.bat or mintty.exe I am getting a basic terminal. 1) The command prompt displays -bash-4.1$ instead of username@directory like before. It sounds like PS1 isn't being set. This is normally done in /etc/profile. You might start by comparing /etc/profile with /etc/defaults/etc/profile. They should be identical unless you've customized /etc/profile at some point. The postinstall script for the base-files package should have taken care of updating /etc/profile, so you could also check to make sure the script was executed. This is probably caused by incorrect permissions in the latest base-files' package contents. A release fixing this will be available shortly. For the time being, please check and correct perms in: /etc/bash.bash_logout /etc/profile.d /etc/profile.d/tzset.sh /etc/profile.d/tzset.csh /etc/profile.d/lang.csh /etc/profile.d/lang.sh /etc/bash.bashrc /etc/skel/.inputrc /etc/skel/.profile /etc/skel/.bashrc /etc/skel/.bash_profile /etc/profile All of them should have owner/group root.root and 644 perms (rw-r--r--) Hope that helps. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files 4.0-9: LANG is set to the system default, why not the user selection?
On Thu, Feb 16, 2012 at 03:24:47PM +0100, Peter Rosin wrote: Mike Kaganski skrev 2012-02-16 14:37: Then you seem to just mock at the maintainer. It's not too polite. Yes, it would be desirable if this effect (and the proposed steps to fix it for those who already use this package) would be noted in the release advertisement. Yes, sometimes even a maintainer may make mistakes on their maintained stuff. But if you have some objections or proposals, it's better to simply say so to people who devote their time and knowledge to us. And append thank you in the end. Look, I was asking honest questions. I was giving David a chance to correct himself, in a case where I wasn't completely sure what was right and wrong, but my gut told me that I was right. Then you jumped in with snide remarks that I should pay attention. To something that happened eons ago! When it was apparent that I already believed the thing I should pay attention to, and was just questioning something that contradicted it! Then I had a more thorough look at things and confirmed my gut reaction. In my eagerness to respond to your snideness I probably misrepresented things so that it seemed like I knew from the start what was going on. So, David, I apologize if I have offended you and it is perhaps best if everybody just forgets everything that has happened in this thread since Mike appeared in it. No need. It looks like I haven't properly understood your complain. Also it looks like I haven't explain properly what was the thing with setting 'locale' both system-wide and user-defined. For the first, I apologize. WRT the second, here's a new attempt: 'locale' is set system-wide in /etc/profile.d/tzset.* to provide a new functionality, that, IIRC, was included in the announcement of the base-files' release. Also, 'locale' _can_ be set at a user-defined level, to provide the user the ability to set 'locale' despite system-wide setting, wich could be needed in multi-user environments, for instance. base-files includes several files that create you $HOME and populate it with the files under /etc/skel/. After that, if you ever modify them, further updates won't affect those files, respecting the policy of not dealing with user modified files (some other distros will prompt you to either install the package version, keep the installed version or see the differences, for example). The scripts that check for existing files, compare them to the package version and perform the update if it has to be done are: /etc/preremove/base-files.sh /etc/postinstall/base-files.sh Your attached .bash_profile does look unmodified, BTW, so regarding the fact it wasn't replaced by the update process, I've tried to reproduce it, unsuccessfully. It works for me. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files problem
On Thu, Feb 16, 2012 at 12:22:25PM -0600, René Berber wrote: Hi, The changes in base-files deleted everything from /etc/skel, I re-installed 4.0-9 and still nothing. I can see in the package list that there should be the usual files there, did some post-install script deleted those files? Anyone seen the same problem? (i.e. your bash prompt changed, no longer shows the current directory). Any idea what is causing this? It started yesterday after I updated a few packages, base-files was not even listed as installed, which is strange, I then re-installed it. I have just updated a box from base-files-4.0-6 to 4.0-9 and everything worked as expected. I tried both with locally modified and unmodified skel files. $ grep base-files /etc/defaults/etc/skel/.* /etc/defaults/etc/skel/.bash_profile:# base-files version 4.0-9 /etc/defaults/etc/skel/.bashrc:# base-files version 4.0-9 /etc/defaults/etc/skel/.inputrc:# base-files version 4.0-9 /etc/defaults/etc/skel/.profile:# base-files version 4.0-9 The process of checking wether the files have to be replaced has not changed since 4.0-4 (march 2011) at least. And IIRC, it was barely the same in the 3.x version as well. If reinstalling fails as well, does an error get printed? -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files problem
On Thu, Feb 16, 2012 at 03:02:16PM -0600, René Berber wrote: On 2/16/2012 2:41 PM, David Sastre Medina wrote: and the files where not deleted, just changed in a way I no longer had a PS1. PS1 is set and exported in /etc/profile I also lost PROMPT_COMMAND which also showed the current directory. The default PROMPT_COMMAND is set (commented) in skeletal .bash_profile to 'history -a', which has nothing to do with showing your PWD. Its possible that I had changed them so the problem is really that those files where replaced, probably my mistake if I had modified the wrong files (I thought the /etc/skel where the ones I should modify, and not touch the /etc/defaults/ files). The test in the preremove step is done comparing the files under /etc/skel against those under /etc/defaults/etc/skel. If locally modified /etc/skel/* files have been removed, that's unexpected. But there is no way installing base-files could partially modify your /etc/skel/* files. Even if they were wrongly replaced, you should have exactly version 4.0-9 files, not partially modified ones. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files 4.0-9: LANG is set to the system default, why not the user selection?
On Thu, Feb 16, 2012 at 09:46:46PM +0100, Peter Rosin wrote: David Sastre Medina skrev 2012-02-16 21:05: As I understand it, base-files contains the file /etc/defaults/etc/skel/.bash_profile. At installation, /etc/postinstall/base-files.sh copies that to /etc/skel/.bash_profile, if it that file doesn't exist already. Then at uninstall, if /etc/preremove/base-files.sh finds that /etc/skel/.bash_profile is not changed, it is removed (so that an updated package feels free to copy over the new version). Further, when a user *first* logs in, /etc/skel/.bash_profile is copied to ~/.bash_profile by the /etc/profile script. At no other point are files in ~ modified, as I understand it. The way I read your explanation above, you are implying that your ~/.bash_profile is updated along with /etc/skel/.bash_profile, and I simply fail to see where that is happening. It is also counter to the message from /etc/profile (also quoted by Mike): Copying skeleton files. These files are for the users to personalise their cygwin experience. They will never be overwritten nor automatically updated. This describes the whole process accurately. I.e. my /etc/skel/.bash_profile is version 4.0-9 as I expect, but my ~/.bash_profile is the old 4.0-6 version from when I first logged in, and I see no code anywhere that checks if ~/.bash_profile matches /etc/skel/.bash_profile and updates if it is pristine. So, the question remains, why is your ~/.bash_profile updated when you upgrade the base-files package? It is not. I re-read the whole thread and found where I lead to you assume that: In http://cygwin.com/ml/cygwin/2012-02/msg00477.html I wrote: Probably you have a customized ~/.bash_profile, so updating to base-files-4.0-9 didn't replace it. But I meant: Probably you have a customized (/etc/skel/).bash_profile, so updating to base-files-4.0-9 didn't replace it. That alone lead to the rest of the mess. Sorry. You need to manually apply changes that happen in skeletal files onto your $HOME if you want them. Also, it should have been explicitly emphasized that, for users in your situation (windows system locale in language A, but user-defined preference to lang B), a manual change was needed to preserve such config. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files problem
On Thu, Feb 16, 2012 at 05:07:40PM -0500, Ken Brown wrote: On 2/16/2012 4:24 PM, Angelo Graziosi wrote: As normal user (not root) $ ls -lrt /etc/defaults/etc/skel/ ls: impossibile aprire la directory /etc/defaults/etc/skel/: Permission denied As root $ ls -lrt /etc/defaults/etc/skel/ totale 0 $ ls -lrt /etc/defaults/etc/ [...] drwxrws---+ 1 root root 0 16 feb 20.07 skel Are these permissions right? The postinstall and preremove scripts also have unusual permissions (not world-readable). The package does have a wrong permissions mask. That may have prevented the execution of preremove/postinstall scripts, but I can't reproduce it. I have downgraded to 4.0-6 and upgraded again without failures, but this cygwin is installed by an Admin user system-wide. I'll release a package correcting the permissions ASAP. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: base-files 4.0-9: LANG is set to the system default, why not the user selection?
On Wed, Feb 15, 2012 at 02:11:14PM +, Andy Koppe wrote:
On 15 February 2012 13:59, Peter Rosin wrote:
My Windows is Swedish, but I generally like it to show as little as
possible in Swedish so my display language is English. I want
English, to not suffer from strange translations that don't make
sense, to be able to search for error messages, etc.
A recent change seems to have LANG set to the output of the system
default language, but I think that's just wrong, it should be the
language of the current user.
Please change lang.{c}sh to do locale -uU instead of locale -sU.
Where is the recommended position to override LANG until such a
change is made, or if it is not an agreeable change?
The files under /etc/profile.d are sourced by /etc/profile, which sets
system wide settings.
For user-defined values, the place to override a system-wide setting
depends on the shell you're using. E.g., for bash, it would be
~/.bash_profile. Check /etc/skel/.bash_profile. It should include
these lines:
# Set user-defined locale
export LANG=$(locale -uU)
Probably you have a customized ~/.bash_profile, so updating to
base-files-4.0-9 didn't replace it.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
[RFU] base-files 4.0-8 [BUGFIX]
Hello, Please upload base-files-4.0-8. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-8.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-8.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[RFU] base-files-4.0-9 [BUGFIX]
Hello, Sorry to bother again. Please upload base-files-4.0-9. Contains a fix for the bug reported in http://cygwin.com/ml/cygwin/2012-02/msg00352.html http://crapsteak.org/cygwin/release/base-files/base-files-4.0-9.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-9.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [RFU] base-files-4.0-9 [BUGFIX]
On Sun, Feb 12, 2012 at 04:10:54PM -0600, Yaakov (Cygwin/X) wrote: On Sun, 2012-02-12 at 22:49 +0100, David Sastre Medina wrote: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-9.tar.bz2 Uploaded. Should 4.0-7 and 4.0-8 be removed? Yes. Thank you. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [ANNOUNCEMENT] Updated: base-files-4.0-7
On Sat, Feb 11, 2012 at 11:11:21PM +1100, Mike Kaganski wrote:
new .bash_profile, line 27:
export LANG=${locale -uU}
looks like it should be
export LANG=$(locale -uU)
Thanks for reporting, and sorry for the inconvenience.
Fixed in base-files-4.0-8.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: bad substitution for LANG in .profile
On Sat, Feb 11, 2012 at 09:56:58AM -0700, Tom Schutter wrote:
With a fresh install of cygwin, this is what I get when I start mintty:
-bash: LANG=${locale -uU}: bad substitution
The bad parameter substitution has been introduced into:
etc/defaults/etc/skel/.profile
etc/defaults/etc/skel/.bash_profile
$ cygcheck -f /etc/defaults/etc/skel/.profile
base-files-4.0-7
Thanks for reporting. Fixed in base-files-4.0-7.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: Updated: base-files-4.0-7
On Sat, Feb 11, 2012 at 11:08:25AM -0800, David Rothenberger wrote: 2/10/2012 2:09 PM, David Sastre Medina wrote: * Environment variable SHELL is now exported from /etc/profile. Improved profile_d() function in /etc/profile - Cyrille Lefevre cygwin.com/ml/cygwin/2011-11/msg00128.html I'm having some troubles due to this change. I'm using bash, and the new /etc/profile exports SHELL=bash. This breaks ssh when using a ProxyCommand. I have this in my ~/.ssh/config file: Host somehost ProxyCommand ssh -q otherhost /usr/bin/nc %h %p When I try to ssh to somehost, I get: % ssh somehost bash: No such file or directory ssh_exchange_identification: Connection closed by remote host If I set SHELL to /bin/bash (which is how it was defaulted before it was set in /etc/profile), everything works fine. Thanks for reporting. Exporting SHELL form /etc/profile was suppossed to add functionality, not to break anything :-/ Anyway, since base-files doesn't know if your shell is /bin/bash, or /usr/local/bin/bash or any other, I think I have to remove it from /etc/profile. Will be fixed in base-files-4.0-8 Sorry for the inconvenience. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[ANNOUNCEMENT] Updated base-files-4.0-8
Version 4.0-8 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Change Log -- 4.0-8 * Bug fix release. Error in commad substitution in .bash_profile and .profile. Reported by Mike Kaganski and Tom Schutter. See cygwin.com/ml/cygwin/2012-02/msg00332.html cygwin.com/ml/cygwin/2012-02/msg00335.html Hardcoding SHELL in /etc/profile broke some configs. Rolled back. Reported by David Rothenberger. See cygwin.com/ml/cygwin/2012-02/msg00341.html *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Updated base-files-4.0-8
On Sun, Feb 12, 2012 at 11:00:07AM -0700, Harry G McGavran Jr wrote: The calls to locale and tzset in profile.d still are not fully qualified. I always thought fully qualified paths were appropriate for system wide scripts since one cannot depend on PATH being set up correctly. In any case, both with the previous release of base-files and this one, if you does something like C:\cygwin\bin\mintty -u - In a shortcut, the /bin isn't in PATH so the calls to locale and tzset fail. make those calls /bin/locale and /bin/tzset (fully qualified) fixes that problem and eliminates the need for PATH to be relied upon in system wide scripts. Harry G. McGavran, Jr. Thanks for reporting. Should be fixed in next release. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[ANNOUNCEMENT] Uploaded base-files-4.0-9
Version 4.0-8 of base-files has been uploaded. Base-files is a set of system configuration and setup files. 4.0-9 * Bug fix release. In profile.d/* scripts, calls to locale and tzset must use absolute paths - Reported by Harry G. McGavran, Jr. See http://cygwin.com/ml/cygwin/2012-02/msg00352.html *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Updated base-files-4.0-8
Version 4.0-8 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Change Log -- 4.0-8 * Bug fix release. Error in commad substitution in .bash_profile and .profile. Reported by Mike Kaganski and Tom Schutter. See cygwin.com/ml/cygwin/2012-02/msg00332.html cygwin.com/ml/cygwin/2012-02/msg00335.html Hardcoding SHELL in /etc/profile broke some configs. Rolled back. Reported by David Rothenberger. See cygwin.com/ml/cygwin/2012-02/msg00341.html *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Uploaded base-files-4.0-9
Version 4.0-8 of base-files has been uploaded. Base-files is a set of system configuration and setup files. 4.0-9 * Bug fix release. In profile.d/* scripts, calls to locale and tzset must use absolute paths - Reported by Harry G. McGavran, Jr. See http://cygwin.com/ml/cygwin/2012-02/msg00352.html *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[ RFU ] base-files-4.0-7
Hello, Please upload base-files-4.0-7. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-7.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-7.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[ANNOUNCEMENT] Updated: base-files-4.0-7
Version 4.0-6 of base-files has been uploaded.
Base-files is a set of system configuration and setup files.
Change Log
--
4.0-7
* Environment variable SHELL is now exported from /etc/profile.
Improved profile_d() function in /etc/profile - Cyrille Lefevre
cygwin.com/ml/cygwin/2011-11/msg00128.html
* TMP and TEMP as defined in the Windows environment must be kept
for windows apps, even if started from cygwin - Atry
cygwin.com/ml/cygwin/2012-01/msg00201.html
* Added two files under /etc/profile.d/ that use tzset, which
uses the geographical location setting of the user to find the right
mapping, rather than the locale setting. Only on Windows 2000 which
doesn't know about the user's geographical location, or if fetching
the geographical location fails, it falls back to the user's locale.
Corrected error in var setting - Corinna Vinschen
See cygwin.com/ml/cygwin-developers/2012-01/msg00042.html,
cygwin.com/ml/cygwin-developers/2012-01/msg00044.html
Updated manifest.
* Added CC0 license header to scripts, and the CC0 license
itself which is under /usr/share/doc/common-licenses/.
Modified locale setting in /etc/profile.d/lang.{sh,csh} to
honor the OS setting.
Corrected some files' header info.
Added Greg's Wiki's URL in /etc/profile.
Bumped version number.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look at the
List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available starting
at this URL.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Updated: base-files-4.0-7
Version 4.0-6 of base-files has been uploaded.
Base-files is a set of system configuration and setup files.
Change Log
--
4.0-7
* Environment variable SHELL is now exported from /etc/profile.
Improved profile_d() function in /etc/profile - Cyrille Lefevre
cygwin.com/ml/cygwin/2011-11/msg00128.html
* TMP and TEMP as defined in the Windows environment must be kept
for windows apps, even if started from cygwin - Atry
cygwin.com/ml/cygwin/2012-01/msg00201.html
* Added two files under /etc/profile.d/ that use tzset, which
uses the geographical location setting of the user to find the right
mapping, rather than the locale setting. Only on Windows 2000 which
doesn't know about the user's geographical location, or if fetching
the geographical location fails, it falls back to the user's locale.
Corrected error in var setting - Corinna Vinschen
See cygwin.com/ml/cygwin-developers/2012-01/msg00042.html,
cygwin.com/ml/cygwin-developers/2012-01/msg00044.html
Updated manifest.
* Added CC0 license header to scripts, and the CC0 license
itself which is under /usr/share/doc/common-licenses/.
Modified locale setting in /etc/profile.d/lang.{sh,csh} to
honor the OS setting.
Corrected some files' header info.
Added Greg's Wiki's URL in /etc/profile.
Bumped version number.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look at the
List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available starting
at this URL.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: rsync 3.0.9 fails when over ssh: connection unexpectedly closed / error in rsync protocol data stream
On Sun, Jan 01, 2012 at 09:27:26PM +0100, Ludovic Aelbrecht wrote: Any help on this would be most appreciated, as I'm really stuck on this. Even just confirmations that rsync over ssh is working for someone (and on what versions of rsync/ssh) would be helpful. $ rsync -av -e ssh test.file.txt dawud@164.0.0.2:downloads/ WARNING: Unauthorized access to this system is forbidden and will be prosecuted by law. By accessing this system, you agree that your actions may be monitored if unauthorized usage is suspected. dawud@164.0.0.2's password: sending incremental file list test.file.txt sent 106 bytes received 31 bytes 24.91 bytes/sec total size is 11 speedup is 0.08 $ cygcheck -c rsync openssh Cygwin Package Information Package VersionStatus openssh 5.9p1-1OK rsync3.0.9-1OK $ uname -a CYGWIN_NT-6.1 win7 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin Works for me. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Problem with execution of binary file
On Fri, Nov 04, 2011 at 06:20:50PM +, Mark Geisert wrote: Eliot Moss writes: I would add that having more than one cygwin installation on the same system can be tricky, since you need to insure that each program gets the right dlls, etc. Sheesh, it's so tricky that I assumed the OP meant he had separate VMs for his two Cygwin installations. If they really are installed on one machine, as the OP said, one 'cygcheck -svr' is enough. I don't think the cygcheck has ever been posted in this thread but is the main requirement asked on http://cygwin.com/problems.html when reporting problems. Also note that the OP is using a home-brewed bash (might be meaningful): 22 111648 [main] bash 536 normalize_posix_path: src /usr/local/bin/bash 23 111671 [main] bash 536 normalize_posix_path: /usr/local/bin/bash = normalize_posix_path (/usr/local/bin/bash) 23 111694 [main] bash 536 mount_info::conv_to_win32_path: conv_to_win32_path (/usr/local/bin/bash) 22 111716 [main] bash 536 set_flags: flags: binary (0x2) 24 111740 [main] bash 536 mount_info::conv_to_win32_path: src_path /usr/local/bin/bash, dst C:\cygwin\usr\local\bin\bash, flags 0x3000A, rc 0 -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: cygwin on virtual box vm
On Fri, Nov 04, 2011 at 03:08:25PM -0600, J.V. wrote: Any other command I type is freakishly slow. How do I get this to run faster under a vm environment. Even if I $vi a file it takes a while seriously cutting into the productivity gains that cygwin on the host environment provides. Please follow the spteps mentioned here to submit a problem report: Problem reports: http://cygwin.com/problems.html When I open a cygwin bash shell, and type '$ls' it just sits there forever. Also, I take for granted you don't type a literal '$ls', and the '$' sign here represents the prompt. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Why 'script' utility require SHELL (and work fine under Linux)?
On Fri, Nov 04, 2011 at 06:05:39AM +0100, Cyrille Lefevre wrote: the base-file maintainer has been BCC'ed to add the export SHELL to the /etc/profile. GNU/Linux login sets SHELL to bash, mksh, ... whilst ssh sets SHELL to /bin/bash, /bin/posh, /bin/mksh ... Given that there is no real login into cygwin (yet?), SHELL should be set to the expected login value. Assuming SHELL would be set and exported for login shells, i.e., further (nested) callings to interactive, non-login shells would inherit the original (login) SHELL value (as in GNU/Linux): $ echo $SHELL bash $ mksh $ echo $SHELL bash It could be fixed for bash, zsh, and mksh. Even for nested calls to login shells (which GNU/Linux doesn't honor) by setting SHELL for every ifdef in /etc/profile. Collateral damage: -posh works OK if set as login shell in /etc/passwd, but it is broken when called from command line as login shell (i.e. it ignores both /etc/profile and ~/.profile) -sh thinks she's bash: $ bash -l $ echo $SHELL bash $ mksh -l $ echo $SHELL mksh $ sh -l $ echo $SHELL bash $ posh -l $ echo $SHELL bash In short: it's not clear to me how to add this functionality consistently. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [ITP] ca-certificates
On Mon, Oct 31, 2011 at 08:58:25PM -0500, Yaakov (Cygwin/X) wrote: On Mon, 2011-10-31 at 21:06 +0100, David Sastre wrote: The cygport 'get' command failed because SRC_URI=fedora/certdata.txt fedora/blacklist.txt fedora/certdata2pem.py Is this intended? Short version: yes, because the files aren't easily wget(1)able. The files are still part of the -src tarball, of course, so this doesn't affect rebuilding from source. Also, in the 'compile' step: /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 26: ident: command not found /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 40: ident: command not found ident is part of the rcs package. I meant to say there's no build requirements list. Looks like you forgot an empty src_test(): Testing ca-certificates-1.78-1 *** ERROR: no Makefile found. You must define your own src_test(). No, there's no testsuite, but it really shouldn't be an error. Fixed in cygport master, commit db03c46. During 'install': *** Warning: Cygwin README is missing Obsolete warning, fixed in cygport master, commit 6f889ab. Thanks, GTG. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Help with ACL and POSIX permissions for external flash/HD.
On Tue, Nov 01, 2011 at 01:38:41PM +0200, Oleksandr Gavenko wrote: 31.10.2011 23:00, David Sastre пишет: YMMV, but 'bash -l' should source your profile settings, both system-wide and user defined. Do you mean bash -i? From the manpage: -i If the -i option is present, the shell is interactive. -l Make bash act as if it had been invoked as a login shell. And: When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc. HTH. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Missing cygmpfr-4.dll
On Tue, Nov 01, 2011 at 12:10:02PM -0700, Thomas Daniel wrote: After a fresh install of cygwin, I am unable to use gcc: /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: cygmpfr-4.dll: cannot open shared object file: No such file or directory Is there any place I could download that library from? http://cygwin.com/cgi-bin2/package-cat.cgi?file=libmpfr4%2Flibmpfr4-3.0.1-1grep=cygmpfr Here is my cygcheck.out: You're suppossed to *attach* it :) 269k 2009/06/07 C:\cygwin\bin\cygmpfr-1.dll - os=4.0 img=1.0 sys=4.0 cygmpfr-1.dll v0.0 ts=2009/6/7 14:10 libmpfr1 2.4.1-4 OK Try installing libmpfr4. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Missing cygmpfr-4.dll
On Tue, Nov 01, 2011 at 01:00:38PM -0700, Thomas Daniel wrote: On 11/1/2011 12:39 PM, David Sastre wrote: On Tue, Nov 01, 2011 at 12:10:02PM -0700, Thomas Daniel wrote: After a fresh install of cygwin, I am unable to use gcc: /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: cygmpfr-4.dll: cannot open shared object file: No such file or directory Is there any place I could download that library from? http://cygwin.com/cgi-bin2/package-cat.cgi?file=libmpfr4%2Flibmpfr4-3.0.1-1grep=cygmpfr Here is my cygcheck.out: You're suppossed to *attach* it :) 269k 2009/06/07 C:\cygwin\bin\cygmpfr-1.dll - os=4.0 img=1.0 sys=4.0 cygmpfr-1.dll v0.0 ts=2009/6/7 14:10 libmpfr1 2.4.1-4 OK Try installing libmpfr4. Thank you for the reply and sorry for including instead of attaching the cygcheck.out. How do I install the libmpfr4 library? So far, I've only used setup.exe and that seems to miss this library. Try another mirror? All the mirrors I've tested do have it, two examples: http://cygwin.cybermirror.org/release/mpfr/libmpfr4/libmpfr4-3.0.1-1.tar.bz2 http://cygwin.petsads.us/release/mpfr/libmpfr4/libmpfr4-3.0.1-1.tar.bz2 -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [ITP] ca-certificates
On Sun, Oct 30, 2011 at 07:19:52PM -0500, Yaakov (Cygwin/X) wrote: While we're waiting for the Tcl/Tk rebuild, with gcc-4.5 out, I can start resyncing the distro with Ports' overrides. ca-certificates contains the Certificate Authority root certificates needed for verifying SSL certificates. It is needed for updating curl and GNOME; wget can can also use it via the ca-certificate option. ftp://ftp.cygwinports.org/pub/cygwinports/release-2/_DISTRO_/ca-certificates/ ca-certificates is already included in all major distros. Hello Yaakov, The cygport 'get' command failed because SRC_URI=fedora/certdata.txt fedora/blacklist.txt fedora/certdata2pem.py $ cygport ca-certificates-1.78-1.cygport get cp: cannot stat `fedora/certdata.txt': No such file or directory *** ERROR: Copying certdata.txt failed Is this intended? Also, in the 'compile' step: /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 26: ident: command not found /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 40: ident: command not found Looks like you forgot an empty src_test(): Testing ca-certificates-1.78-1 *** ERROR: no Makefile found. You must define your own src_test(). During 'install': *** Warning: Cygwin README is missing -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Help with ACL and POSIX permissions for external flash/HD.
On Mon, Oct 31, 2011 at 10:39:27PM +0200, Oleksandr Gavenko wrote: 30.10.2011 23:24, Oleksandr Gavenko пишет: How can I set umask? In .bashrc? Umask is already set system-wide in /etc/profile: # Default to removing the write permission for group and other # (files normally created with mode 777 become 755; files created with # mode 666 become 644) umask 022 And user-defined in ~/.bashrc # /etc/profile sets 022, removing write perms to group + others. # Set a more restrictive umask: i.e. no exec perms for others: # umask 027 # Paranoid: neither group nor others have any perms: # umask 077 Check under /etc/defaults/etc. What if I run Cygwin program from cmd? YMMV, but 'bash -l' should source your profile settings, both system-wide and user defined. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Contributing license information?
On Tue, Oct 25, 2011 at 03:50:45PM +0200, Corinna Vinschen wrote: On Oct 25 12:00, Luke Kendall wrote: Corinna Vinschen wrote: On Aug 19 11:09, Luke Kendall wrote: Soon, I will have prepared a list of the location of every license file in every Cygwin package. My motivation is to make it easy for people to find the license information, if they need it. (Preparing this information has required a lot of work on my part, so I would be happy if something could be done to make it easy to keep the information up to date as packages are added and modified.) What is the best way to contribute the license-location information so it can be integrated into Cygwin? Just create a new package for the distro which keeps the information and maintain it. Somebody will have to keep the information up to date anyway. Is usr/share/doc/common-licenses/ within the base-files package, supposed to be the place where all license information is collected? Should I just use that instead of creating a new package? Sure, why not, if that's ok with David. You can also rip out the usr/share/doc/common-licenses directory from base-files and create a licenses package with all licenses. Just as you two want it. There's also another solution: include licensing information within base-files, and co-mantain it. It's already under version control. Luke, if it's ok with you, I'd go this way. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: lost announcements
On Mon, Oct 24, 2011 at 04:16:18PM -0400, Andrew Schulman wrote: This morning I sent 4 package update announcements to cygwin-announce. Two of them (socat, lftp) were posted, but the other two (stunnel, sng) haven't shown up yet. Meanwhile, other later announcements have been posted. Are the missing messages held up in the queue? Anything I need to do about that? Or, should I resend them? Thanks, Andrew. I have received them, and they both show in the web: http://cygwin.com/ml/cygwin-announce/2011-10/msg00036.html http://cygwin.com/ml/cygwin-announce/2011-10/msg00035.html -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: lost announcements
On Mon, Oct 24, 2011 at 05:20:52PM -0400, Andrew Schulman wrote: On Mon, Oct 24, 2011 at 04:16:18PM -0400, Andrew Schulman wrote: This morning I sent 4 package update announcements to cygwin-announce. Two of them (socat, lftp) were posted, but the other two (stunnel, sng) haven't shown up yet. Meanwhile, other later announcements have been posted. Are the missing messages held up in the queue? Anything I need to do about that? Or, should I resend them? I have received them, and they both show in the web: http://cygwin.com/ml/cygwin-announce/2011-10/msg00036.html http://cygwin.com/ml/cygwin-announce/2011-10/msg00035.html Hm, you're right. But the odd thing is that they weren't posted to the cygwin list, which is where I read them: http://cygwin.com/ml/cygwin/2011-10/. Any idea why? Nope. And I'm afraid I can't help there. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Contributing license information?
On Fri, Oct 21, 2011 at 10:59:01AM +0200, Corinna Vinschen wrote: On Oct 21 13:02, Luke Kendall wrote: Can I ask a related question: for the few shell scripts and /etc files provided in base-files: what license are they under? The package contains lots of licenses, as we've been discussing, but I couldn't find any indication of which license applies to the actual non-license files in base-files itself! Isn't that hard on the verge of nit-picking? These are simple scripts. Their Linux brothers and sisters are under PD so I think it makes much sense to define the Cygwin files as PD, too. David, that's ok with you? Yes, it's ok for me :) Also, it's possible to specifically mention it in the header of every shellscript in base-files, maybe using CC0[1][2]? CC0 would then be included under /usr/share/doc/common-licenses. Please note IANAL, i.e., I'm not aware of possible uncompatibilities of CC0 with the rest of the project's licensing. (Generally speaking, it's an interesting topic, BTW.[3]) [1]https://www.gnu.org/licenses/license-list.html#CC0 [2]https://creativecommons.org/publicdomain/zero/1.0/legalcode [3]https://secure.wikimedia.org/wikipedia/en/wiki/Public_domain -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: openssh authentification
On Fri, Oct 14, 2011 at 01:43:57PM -0500, Clayton Evans wrote: debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method So all three of those keys were offered, but none were accepted. Are the public keys for those in your ~/.ssh/authorized_keys file on the server? I copied the .ssh/authorized_keys file from the client to the host before the ssh -vvv jti031 was done. OK, but that's not exactly what I asked. The question is, is one of those public keys (/home/cevans/.ssh/id_rsa.pub, /home/cevans/.ssh/id_dsa.pub, or /home/cevans/.ssh/id_ecdsa.pub from the client) in ~/.ssh/authorized_keys on the server? No, the id_*.pub files were not copied. I have now copied all three id_*.pub files from the client to the host. I have rerun 'ssh -vvv jti031' with identical results. (At least diff finds the results to be identical.) I'd double-check StrictModes and PubkeyAuthentication in sshd_config. Also, there's no need to copy around your pub keys manually, use ssh-copy-id(1) for that. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Runtime error
On Fri, Oct 14, 2011 at 11:49:31AM +0200, phi...@free.fr wrote: Hello, I have just installed cygwin on Windows 7 and I get the following runtime error once every so often: Runtime Error! Program c:\cygwin\bin\bash.exe R6016 - not enough space for thread data Please follow the directions in Problem reports: http://cygwin.com/problems.html Furthermore, when I open a terminal and source my old .bashrc file, the following message appear four times: -bash: /home/myname is a directory Noone of us know the contents of you bashrc, so it's difficult to guess. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: openssh authentification
On Fri, Oct 14, 2011 at 03:28:14PM -0500, Clayton Evans wrote: I'd double-check StrictModes and PubkeyAuthentication in sshd_config. ssh-copy-id requires that password authentication is working, which is not happening, so I tried manual moving of the files Sorry, I obviously overlooked that. I assume sshd_config is properly configured to allow public key authentication. Have you checked your /etc/passwd and /etc/group files? Does the user guide¹ help? ¹http://cygwin.com/cygwin-ug-net/ntsec.html -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Where is /bin/nologin
On Thu, Oct 13, 2011 at 11:37:19AM -0700, gwodus wrote: I am missing /bin/nologin. I need to disable shell access for a user. But it still needs to be able to accept ssh connects for tunnel only for that user (ssh -N ...). On Linux I would set the login shell in /etc/passed to /sbin/nologin. But I can't find it on cygwin. Is there a certain cygwin package I need to install? Thanks in advance, gwodus. Does /bin/false serve that purpose? -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: cygwin started speaking German today
On Tue, Sep 13, 2011 at 09:45:37AM -0600, Eric Blake wrote:
On 09/09/2011 08:59 AM, Corinna Vinschen wrote:
On Sep 9 13:33, Andy Koppe wrote:
The 'C.UTF-8' default locale is not a bug, it was a deliberate design
decision.
Exactly. And it has been discussed a lot on the cygwin-apps mailing
list.
And above all, there *is* an official way for the user to align the
Cygwin locale with the Windows locale, see the -s and -u options
of the locale(1) command:
http://cygwin.com/cygwin-ug-net/using-utils.html#locale
On 09/09/2011 09:09 AM, Corinna Vinschen wrote:
OK, then the following four facilities are needed in Cygwin.
1) We need the name of the locale which is in effect when the user has
not specified environment variables.
In Fedora, for instance, the fallback is what is set as system default
in /etc/sysconfig/i18n.
In Cygwin the fallback is the system default set in
/etc/profile.d/lang.sh
or /etc/profile.d/lang.csh.
Why should libintl use anything else on Cygwin, but not on Linux?
Given this, I think the bug is in cygwin for having base files
/etc/profile.d/lang.{sh,csh} which hardcode LANG to C.UTF-8 instead
of using locale -s -u to default LANG to the preferred Windows
settings. Libintl should NOT be second-guessing an explicit setting
of LANG, but cygwin should NOT be explicitly setting LANG to C.UTF-8
in its default startup scripts without any regards to the Windows
settings. Whether setlocale(LC_ALL,) returns C.UTF-8 or a
Windows-appropriate string _when LANG is undefined_ is still worth
solving, but right now, an out-of-the-box cygwin installation
_always has LANG defined_ by the default startup scripts. So our
first focus should be to get that setting of LANG fixed to honor
Windows, and to teach libintl that when LANG is set we really meant
it.
WRT the base-files package, would it be acceptable/does it make sense to set:
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=${locale -sU}
in /etc/profile.d/lang.sh and
if ( $?LC_ALL == 0 $?LC_CTYPE == 0 $?LANG == 0 ) setenv LANG = `locale
-sU`
in /etc/profile.d/lang.csh, both as proposed, _and_ a (possibly) commented-out
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=${locale -uU}
in the skeletal .bash_profile and .profile (i.e. both system-wide and
user defined settings)?
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: cygwin started speaking German today
On Sat, Sep 17, 2011 at 05:49:54PM -0400, Ken Brown wrote:
On 9/17/2011 4:40 PM, David Sastre wrote:
On Tue, Sep 13, 2011 at 09:45:37AM -0600, Eric Blake wrote:
On 09/09/2011 08:59 AM, Corinna Vinschen wrote:
On Sep 9 13:33, Andy Koppe wrote:
The 'C.UTF-8' default locale is not a bug, it was a deliberate design
decision.
Exactly. And it has been discussed a lot on the cygwin-apps mailing
list.
And above all, there *is* an official way for the user to align the
Cygwin locale with the Windows locale, see the -s and -u options
of the locale(1) command:
http://cygwin.com/cygwin-ug-net/using-utils.html#locale
On 09/09/2011 09:09 AM, Corinna Vinschen wrote:
OK, then the following four facilities are needed in Cygwin.
1) We need the name of the locale which is in effect when the user has
not specified environment variables.
In Fedora, for instance, the fallback is what is set as system default
in /etc/sysconfig/i18n.
In Cygwin the fallback is the system default set in
/etc/profile.d/lang.sh
or /etc/profile.d/lang.csh.
Why should libintl use anything else on Cygwin, but not on Linux?
Given this, I think the bug is in cygwin for having base files
/etc/profile.d/lang.{sh,csh} which hardcode LANG to C.UTF-8 instead
of using locale -s -u to default LANG to the preferred Windows
settings. Libintl should NOT be second-guessing an explicit setting
of LANG, but cygwin should NOT be explicitly setting LANG to C.UTF-8
in its default startup scripts without any regards to the Windows
settings. Whether setlocale(LC_ALL,) returns C.UTF-8 or a
Windows-appropriate string _when LANG is undefined_ is still worth
solving, but right now, an out-of-the-box cygwin installation
_always has LANG defined_ by the default startup scripts. So our
first focus should be to get that setting of LANG fixed to honor
Windows, and to teach libintl that when LANG is set we really meant
it.
WRT the base-files package, would it be acceptable/does it make sense to set:
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=${locale -sU}
in /etc/profile.d/lang.sh and
if ( $?LC_ALL == 0 $?LC_CTYPE == 0 $?LANG == 0 ) setenv LANG = `locale
-sU`
in /etc/profile.d/lang.csh, both as proposed, _and_ a (possibly)
commented-out
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=${locale -uU}
in the skeletal .bash_profile and .profile (i.e. both system-wide and
user defined settings)?
If you want the user-defined setting to take effect, wouldn't you
have to omit the `test -z ...'? LANG will already be set when
.bash_profile is processed.
Indeed, excuse the fast copy-paste. The proposal still stands.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: dash incompatibility in /etc/profile
2011/8/21, Charles Wilson wrote:
Running 'dash -l' flags an error in /etc/profile:
if [[ -n ${BASH_VERSION} ]]; then
HOSTNAME=$(/usr/bin/hostname)
profile_d sh
[[ -f /etc/bash.bashrc ]] . /etc/bash.bashrc
elif [[ -n ${KSH_VERSION} ]]; then
typeset -l HOSTNAME=$(/usr/bin/hostname)
profile_d sh
PS1=$(print
'\033]0;${PWD}\n\033[32m${USER}@${HOSTNAME}\033[33m${PWD/${HOME}/}\033[0m\n$
')
elif [[ -n ${ZSH_VERSION} ]]; then
HOSTNAME=$(/usr/bin/hostname)
profile_d zsh
PS1='(%n@%m)[%h] %~ %% '
these uses of '[[' are not supported by dash, although apparently posh
supports them.
I was trying to launch 'dash' from cmd.exe, in such a way that the
default Windows values of TMP, TMPDIR, and TEMP were overridden. For
now I can do
set ENV=~/.dashinit
dash
but...can we use /bin/test or a regular '[' here?
--
Chuck
Hello,
Can you please check which version of base-files here you using?
In 4.0-6 I have:
if [ ! x${BASH_VERSION} = x ]; then
HOSTNAME=$(/usr/bin/hostname)
profile_d sh
[ -f /etc/bash.bashrc ] . /etc/bash.bashrc
elif [ ! x${KSH_VERSION} = x ]; then
typeset -l HOSTNAME=$(/usr/bin/hostname)
profile_d sh
PS1=$(print '\033]0;${PWD}\n\033[32m${USER}@${HOSTNAME}
\033[33m${PWD/${HOME}/~}\033[0m\n$ ')
elif [ ! x${ZSH_VERSION} = x ]; then
HOSTNAME=$(/usr/bin/hostname)
profile_d zsh
PS1='(%n@%m)[%h] %~ %% '
elif [ ! x${POSH_VERSION} = x ]; then
HOSTNAME=$(/usr/bin/hostname)
PS1=$
else
HOSTNAME=$(/usr/bin/hostname)
profile_d sh
PS1=$
fi
As per:
Change Log
--
4.0-6
* Dropped non-POSIX tests in /etc/profile - Eric Blake
cygwin.com/ml/cygwin/2011-03/msg00510.html
Maybe you modified /etc/profile preventing it to get updated before 4.0-6.
--
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: m4 1.4.16-1 doesn't seem to work
On Fri, Jun 17, 2011 at 05:16:02PM +, Vadim Zeitlin wrote: Uday S Reddy u.s.reddy at cs.bham.ac.uk writes: Eric Blake writes: Odd; that says all your dlls are in place. The only other thing that I can suspect is that you have an incomplete dll, where you are missing a required entry point (perhaps you are running too old of a cygwin1.dll?). What is $? after the failed m4? Also, can you try opening up a cmd window, and running m4 from there, to see if you get a useful popup box? (running under a cygwin shell intentionally suppresses dll link error popup boxes) Indeed, you were right to suspect the dll. Reinstalling it cured the problem. Sorry to revive a relatively old thread but I have the same problem as Uday except that I couldn't fix it. To summarize: 1. After a routine Cygwin upgrade m4 stopped working, it exits with $?=127 without any messages, even when ran from cmd.exe and not Cygwin prompt. 2. Reinstalling m4 1.4.16 didn't change anything. 3. Rolling back to 1.4.15 fixed the problem and m4 runs ok now. 4. Re-upgarding to 1.4.16 reintroduced the same problem so it wasn't just a bad upgrade or something like that. The output of cygcheck is the same for 1.4.15 and 1.4.16. However the output of ldd is normal for 1.4.15 but ldd hangs with 1.4.16 with m4 child process running but not doing anything. So it seems to me that there is a real problem with m4 1.4.16. Unfortunately I don't know how to debug it further. For the moment I'm just going to stay with 1.4.15 but if anybody has any ideas for further tests I'd be glad to perform them and post the results. You could download the source package, build it and try to see if it makes a difference. Just an idea. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: iconv capability removed from rsync 3.0.8
On Tue, May 31, 2011 at 11:03:06AM +0200, Fernando Molina Ortiz wrote: I have noticed that the iconv capability is not activated anymore in rsync 3.0.8, while in rsync 3.0.7 it is. When cally rsync --version, in 3.0.7 iconv is listed in the capabilities section, while in 3.0.8 it appears as 'no iconv'. I use it, so I had to downgrade. Does anybody know why it's beed removed? It could be a packaging issue, FWIW building from the sources enables iconv support. Rsync from the repo: $ rsync --help | head rsync version 3.0.8 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, no iconv, symtimes Rsync rebuild from sources: $ ./rsync-3.0.8-1/inst/usr/bin/rsync.exe --help | head rsync version 3.0.8 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Error building run2 from source package in win7
On Tue, May 24, 2011 at 05:10:37PM -0400, Charles Wilson wrote:
On 5/24/2011 3:53 PM, David Sastre wrote:
On Tue, May 24, 2011 at 02:59:11PM -0400, Charles Wilson wrote:
A-ha!
Don't set -Werror as part of $CC, set it in $CFLAGS instead.
Which is what is defined in the *.cygport's src_compile func:
src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf CFLAGS=-Wall -Werror
cygmake
}
And I'm doing nothing but running 'cygport *.cygport all'.
Well, Eric is the real expert, and he says don't set the warning flags
until the cygmake line, so that's first. However, I assume the
incantation above worked in the past for the original author of the
.cygport(5) file, so why's it breaking for you?
Second, why does the STC below not work for you, when it worked for me?
for the same reasons (config.log):
configure:2563: gcc -c -Wall -Werror conftest.c 5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:38:10: error: 't' is used uninitialized in this function
conftest.c:54:23: error: 'b' may be used uninitialized in this
function
configure:2563: $? = 1
Well, looking at my config.log, I too have:
configure:2498: checking for an ANSI C-conforming const
configure:2563: gcc -c -Wall -Werror conftest.c 5
^
configure:2563: $? = 0
configure:2570: result: yes
but we already know that this conftest.c is not -Wall -Werror clean --
or, at least, that YOUR conftest.c is not clean.
Digging deeper in my configure, I find that the test uses the shell
function ac_fn_c_try_compile(), and that shell function has an
interesting bit of code:
1340 test -z $ac_c_werror_flag ||
1341 test ! -s conftest.err
1342} test -s conftest.$ac_objext; then :
1343 ac_retval=0
Hmmm...it's checking something to do with a Werror flag! Maybe there's
a workaround, but (a) is only activated if the -Werror is in CFLAGS, not
CC -- otherwise *I* would have passed the STC with CC='gcc -Wall
-Werror' but I didn't, and (b) its only present in specific (newer?)
versions of autoconf, and you and I are using different versions.
Here's the first 3 lines of my configure script:
1 #! /bin/sh
2 # Guess values for system-dependent variables and create Makefiles.
3 # Generated by GNU Autoconf 2.68.
What's yours say?
Autoconf version matches yours:
$ cygcheck -c autoconf2.5
Cygwin Package Information
Package VersionStatus
autoconf2.5 2.68-1 OK
$ head -3 configure
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.68 for run2 0.4.0.
Moving the -Werror flag to the cygmake step did the trick:
$ diff -u run2-0.4.0-1.cygport.orig run2-0.4.0-1.cygport
--- run2-0.4.0-1.cygport.orig 2009-12-29 07:30:19.0 +0100
+++ run2-0.4.0-1.cygport2011-05-25 11:11:51.13920 +0200
@@ -11,7 +11,7 @@
cd ${S}
cygautoreconf
cd ${B}
- cygconf CFLAGS=-Wall -Werror
- cygmake
+ cygconf CFLAGS=-Wall
+ cygmake CFLAGS=-Werror
}
checking for an ANSI C-conforming const... yes
I've been able to compile without problems.
Thanks for your time.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: Error building run2 from source package in win7
On Mon, May 23, 2011 at 02:33:56PM -0400, Charles Wilson wrote:
On 5/23/2011 1:22 PM, Eric Blake wrote:
On 05/23/2011 11:17 AM, David Sastre wrote:
cc1: warnings being treated as errors
/usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In
function 'run2_strtol':
/usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3:
error: passing argument 3 of '__assert_func' discards qualifiers from
pointer target type
/usr/include/assert.h:41:6: note: expected 'char *' but argument is of
type 'const char *'
The signature in assert.h uses 'const char *'; I would have to suspect
that somewhere in your build process you have a stray:
#define const
getting in the way,
I think this is the only possibility, because...
and that this is thus a bug in the run2 sources and
not in cygwin headers.
FWIW, I never meant to have found a bug in cygwin nor in the run2 sources.
I'm just failing to build it and I hoped your wisdom might help me.
...the code does this:
int
run2_strtol(char *arg, long *value)
{
char *endptr;
int errno_save = errno;
assert(arg!=NULL);
However, the stringization of the expression 'arg!=NULL' is passed as
arg #4 (and the expression itself doesn't appear in the argument list of
__assert_func at all; see definition below). Anyway, the #3 argument of
__assert_func is __ASSERT_FUNC:
# define assert(__e) ((__e) ? (void)0 : \
__assert_func (__FILE__, __LINE__, \
__ASSERT_FUNC, #__e))
and __ASSERT_FUNC is defined as
__PRETTY_FUNCTION__
__func__
or__FUNCTION__
depending on the compiler and various flags. Now, since these are
built-ins, the signature is fixed: they are all const char*. So the
only way you could get this warning/error is if assert.h is messed up
somehow...e.g. as Eric suggests, because an earlier header has #defined
const away before the following decl in assert.h is parsed:
void _EXFUN(__assert_func, (const char *, int, const char *,
const char *) _ATTRIBUTE ((__noreturn__)));
Thanks both for the educational explanation.
Now, where could a #define const occur?
$ find ${run2_srcdir} -type f |\
xargs grep const | grep define | grep '#'
./configure:$as_echo #define const /**/ confdefs.h
...more checking...Ah, this is part of the configure macro AC_C_CONST.
hmm...maybe the OP should check his generated config.h file for the
offending def. If it's there, a quick look inside config.log should
tell you why 'checking for an ANSI C-conforming const' is reporting 'no'.
$ grep -nR define const run2-0.4.0-1/build/config.h
152:#define const /**/
From the config.log:
configure:12737: checking for an ANSI C-conforming const
configure:12802: gcc -c -Wall -Werror conftest.c 5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:69:10: error: 't' is used uninitialized in this function
conftest.c:85:23: error: 'b' may be used uninitialized in this function
configure:12802: $? = 1
configure: failed program was:
(snipped defines and removed comments)
| int
| main ()
| {
| #ifndef __cplusplus
| typedef int charset[2];
| const charset cs;
| char const *const *pcpcc;
| char **ppc;
| struct point {int x, y;};
| static struct point const zero = {0,0};
| const char *g = string;
| pcpcc = g + (g ? g-g : 0);
| ++pcpcc;
| ppc = (char**) pcpcc;
| pcpcc = (char const *const *) ppc;
| {
| char *t;
| char const *s = 0 ? (char *) 0 : (char const *) 0;
|
| *t++ = 0;
| if (s) return 0;
| }
| {
| int x[] = {25, 17};
| const int *foo = x[0];
| ++foo;
| }
| {
| typedef const int *iptr;
| iptr p = 0;
| ++p;
| }
| {
|k.c, line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. */
| struct s { int j; const int *ap[3]; };
| struct s *b; b-j = 5;
| }
| {
| const int foo = 10;
| if (!foo) return 0;
| }
| return !cs[0] !zero.x;
| #endif
|
| ;
| return 0;
| }
configure:12809: result: no
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: Error building run2 from source package in win7
On Tue, May 24, 2011 at 02:59:11PM -0400, Charles Wilson wrote:
On 5/24/2011 2:38 PM, David Sastre wrote:
hmm...maybe the OP should check his generated config.h file for the
offending def. If it's there, a quick look inside config.log should
tell you why 'checking for an ANSI C-conforming const' is reporting 'no'.
$ grep -nR define const run2-0.4.0-1/build/config.h
152:#define const /**/
From the config.log:
configure:12737: checking for an ANSI C-conforming const
configure:12802: gcc -c -Wall -Werror conftest.c 5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:69:10: error: 't' is used uninitialized in this function
conftest.c:85:23: error: 'b' may be used uninitialized in this function
Looks like a possible bug in autoconf, which is where the definition of
AC_C_CONST comes from -- or they might define this as PIBKAC (see
below). The test really ought to be -Wall -Werror friendly, but that's
up to the autoconf guys.
(snip)
$ ./configure CC=gcc -Wall -Werror
checking for gcc... gcc -Wall -Werror
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -Wall -Werror accepts -g... yes
checking for gcc -Wall -Werror option to accept ISO C89... none needed
checking for an ANSI C-conforming const... no
A-ha!
Don't set -Werror as part of $CC, set it in $CFLAGS instead.
Which is what is defined in the *.cygport's src_compile func:
src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf CFLAGS=-Wall -Werror
cygmake
}
And I'm doing nothing but running 'cygport *.cygport all'.
This test is failing for me:
$ cat configure.ac
AC_INIT([test])
AC_CONFIG_SRCDIR([configure.ac])
AC_C_CONST
$ autoconf
$ ./configure CFLAGS=-Wall -Werror
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for an ANSI C-conforming const... no
for the same reasons (config.log):
configure:2563: gcc -c -Wall -Werror conftest.c 5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:38:10: error: 't' is used uninitialized in this function
conftest.c:54:23: error: 'b' may be used uninitialized in this
function
configure:2563: $? = 1
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: CYGWIN=tty round 2
On Mon, May 23, 2011 at 11:35:40AM +0200, Sven Köhler wrote: Am 22.05.2011 23:19, schrieb Christopher Faylor: mintty I have the feeling, you should make mintty default :-) (for startup menu shortcuts, etc.) http://cygwin.com/ml/cygwin-apps/2010-05/msg00082.html -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
