Re: [PATCH 2/4] Canonicalize mirror URLs to ensure they end with a '/'
On Nov 26 13:48, Jon TURNEY wrote: This prevents a mirror URL being added twice (with and without a terminal '/') This ensures that the download directory is consistently named, avoiding downloading everything again, even if an additional mirror URL is added in a form which differs in the presence of a terminal '/' from last time. 2010-11-26 Jon TURNEY jon.tur...@dronecode.org.uk * site.cc (init): Canonicalize mirror URLs to ensure the end with a '/'. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- site.cc |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/site.cc b/site.cc index 42839f3..ff617b5 100644 --- a/site.cc +++ b/site.cc @@ -141,6 +141,10 @@ site_list_type::init (const string _url, const string _servername, area = _area; location = _location; + /* Canonicalize URL to ensure it ends with a '/' */ + if (url.at(url.length()-1) != '/') +url.append(/); + /* displayed_url is protocol and site name part of url */ string::size_type path_offset = url.find (/, url.find (//) + 2); displayed_url = url.substr(0, path_offset); -- Looks good, please apply. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH 3/4] Make io_stream::exists() directory aware
On Nov 26 13:48, Jon TURNEY wrote:
At the moment io_stream::exists() returns FALSE for file:// paths
which refer to an existing directory. Inconsistently, for
cygfile:// paths which refer to an existing directory, it returns
TRUE.
Return a new state, IO_STREAM_EXISTS_DIRECTORY, to indicate if
pathname exists as a directory and update all uses appropriately
Not sure if the use of access() in the legacy branch of
io_stream_cygfile::exists() is correct, looks like it's inverted
Indeed.
Not sure if current exists() implementation deals correctly when other
attributes are set for a file, e.g. FILE_ATTRIBUTE_COMPRESSED or
FILE_ATTRIBUTE_ENCRYPTED, since it checks attributes against an
expected value rather than checking for bits being set?
No, the original implementation certainly doesn't look quite right.
@@ -196,11 +197,21 @@ io_stream_cygfile::exists (const std::string path)
mklongpath (wname, cygpath (normalise(path)).c_str (), len);
DWORD attr = GetFileAttributesW (wname);
if (attr != INVALID_FILE_ATTRIBUTES)
- return 1;
+return (attr FILE_ATTRIBUTE_DIRECTORY) ?
IO_STREAM_EXISTS_DIRECTORY : IO_STREAM_EXISTS_FILE;
}
else if (_access (cygpath (normalise(path)).c_str (), 0))
-return 1;
- return 0;
+{
+ struct _stat s;
+ if (!_stat (cygpath (normalise(path)).c_str (), s))
+{
+ if (s.st_mode S_IFDIR)
+return IO_STREAM_EXISTS_DIRECTORY;
+
+ if (s.st_mode S_IFREG)
+return IO_STREAM_EXISTS_FILE;
+}
+}
+ return IO_STREAM_EXISTS_NO;
}
I would prefer if you would use GetFileAttributesA here, just like the
io_stream_file::exists method. This also unifies testing the
attributes.
Other than that, the patch looks good to me.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [PATCH 4/4] Use site download directory without trailing %2f if it doesn't already exist
On Nov 26 13:48, Jon TURNEY wrote: Centralize where download directory is chosen Use site download directory without trailing %2f if it doesn't already exist 2010-11-26 Jon TURNEY jon.tur...@dronecode.org.uk * package_source.h (site): Add get_local_path() method and storage * package_source.cc (get_local_path): Implement get_local_path() method, to determine local directory to use for downloads from site. * ini.cc (do_remote_ini): Use get_local_path() * download.cc (check_for_cached, download_one): Use get_local_path() That one looks good, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH 1/4] Add the last element of URL path to site chooser, if interesting.
On Nov 26 13:48, Jon TURNEY wrote: Currently, for example, if I manually add the site http://mirrors.kernel.org/sources.redhat.com/cygwinports/ to setup's mirror list, I get two indistinguishable entries named http://mirrors.kernel.org. Furthermore, because the code to ensure the site just added is selected uses the string inside the list control to locate elements, we end up with a random one of those two indistinguishable entries selected (usually the previously existing one). This problem also prevents the selected sites being correctly saved and restored for the next setup run. So, to make the site chooser list entries unique and distinguishable, add the last element of the URL path to the site chooser, if it exists and isn't 'cygwin' (or some other alternatives used by current mirrors) That sounds a bit problematic. So two URLs on the same machine might again end up as the same string, undistinguishable, just because they both end in the same directory name? And there are (right now) four such directory names, which are treated identically. Don't get me wrong. It's certainly better than what we have today, and the full URL is almost unreadable. Nevertheless, I'd be more happy with a solution which fixes this problem even for such border cases... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] tftp-hpa 5.0
On 11/20/2010 2:04 AM, Charles Wilson wrote: On 11/19/2010 10:59 AM, Gernot Hillier wrote: On 17.11.2010 06:32, Charles Wilson wrote: We'll have to coordinate a) uploading the tftp and the updated inetutils packages, and b) sending the announcements of those two packages I'll need some time for (a) because I have to update inetutil's iu-config and syslog-config scripts; fortunately the major surgery -- removing tftp/tftpd -- from inetutils is already done. Just let me know then when you're ready. Will do. BTW, just so that the checksums are all consistent, you should probably rebuild 5.0-3 yourself, and then upload /your/ tarballs somewhere, so that we can make sure that /your/ versions get uploaded to sourceware. FWIW, I have a new inetutils package (without tftp/tftpd) ready to go. Do you have (rebuilt) tftp-5.0-3 packages ready for upload? -- Chuck
Do we need a new maintainer for fetchmail?
Greetings, the fetchmail package for Cygwin is at version 6.3.9, released two years ago, and with known security vulnerabilities and errata: CVE-2009-2666 - improper TLS cert validation allows MITM attacks to go unnoticed CVE-2010-1167 - heap overflow in verbose mode EN-2010-03- improper SASL/AUTH implementation causes bogus auth failures And a gazillion of bugfixes since 6.3.9 provided in [1], including critical fixes for long-standing bugs. Fetchmail does not currently require Cygwin-specific patches. I have provided Jason Tishler with up to date packages for the current fetchmail 6.3.18 package (with selected upstream fixes from post-6.3.18 Git) a fortnight ago, built on Cygwin 1.7.7 32-bit (Win 7), without any response. I don't mean to take over maintainership, but -- can we do non-maintainer updates in such situations? Best regards Matthias, upstream fetchmail maintainer [1] http://gitorious.org/fetchmail/fetchmail/blobs/master/NEWS#line57 -- Matthias Andree
src/winsup/cygwin ChangeLog fhandler_tty.cc path.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-11-29 20:51:39 Modified files: winsup/cygwin : ChangeLog fhandler_tty.cc path.h Log message: * fhandler_tty.cc (fhandler_tty_slave::dup): Free path_conv strings to avoid memory leak. Add comment. (fhandler_pty_master::dup): Ditto. * path.h (path_conv::free_strings): New method. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5097r2=1.5098 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=srcr1=1.215r2=1.216 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.h.diff?cvsroot=srcr1=1.152r2=1.153
Re: File paths redirected to MSYS directory
You're probably invoking MSYS's versions of vi and make. You can check that with the which command. Ensure that you do have the Cygwin versions of those installed, and that the Cygwin bin directory comes before MSYS's in the Cygwin PATH. To avoid such confusion, you might want to remove MSYS's bin directory from the global Windows path, assuming that's where it came from. Andy Thanks for your help. I have fixed the Windows path but Cygwin seems to be altering it when loading it in to its own $PATH environment variable. Compare below, my path as obtained from Windows cmd console and from Cygwin. Notice the line 'C:\cygwin\bin' in the first one (end of the second line) has been turned in to '/usr/bin' in the second one (end of the third line). Why would this be happening? Also, is it a problem that the first two entries in the Cygwin path are '/usr/...' rather than '/cygdrive/c/cygwin/usr/...' ? Windows: C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\SYSTEM32\Wbem;C:\Program Files\Novell\ ZENworks\;C:\Program Files\QuickTime\QTSystem\;C:\MinGW\bin;C:\cygwin\bin;C:\msy s\1.0\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Novell\GroupWise;C:\ Program Files\Putty;C:\GTK\2.0\bin;C:\Program Files\SSH Communications Security\ SSH Secure Shell;Z:.;Y:.; Cygwin: /usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/System32:/cygdrive/c/WINDOWS:/c ygdrive/c/WINDOWS/SYSTEM32/Wbem:/cygdrive/c/Program Files/Novell/ZENworks/:/cygd rive/c/Program Files/QuickTime/QTSystem/:/cygdrive/c/MinGW/bin:/usr/bin:/cygdriv e/c/msys/1.0/bin:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/c/Program F iles/Novell/GroupWise:/cygdrive/c/Program Files/Putty:/cygdrive/c/GTK/2.0/bin:/c ygdrive/c/Program Files/SSH Communications Security/SSH Secure Shell:Z:.:Y:. Thanks, Nathan -- 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: R: Question about cygwin installation and folder permissions
Greetings, Vincent Richomme! run setup and choose the directory you want the default proposal is c:\cygwin To add: Strongly advised against paths with spaces or national letters. Again I was not very clear I don't want to know how to install cygwin because even a monkey can do it. No what I want to know is in the installer how do you change folder permissions, what kind of API, is it done by the installer or by some post install script... Erm, wat? Sorry, but I quite don't understand, what the end-result you want? Cygwin is installed in userspace. You could even install it in your profile directory (assuming you're on Vista/W7). Where can I find cygwin installer sources if it's done by it. Actually I built a custom installer for msys/mingw-w64 and when I install it in C:/Developer/MaxGW, if I run it without permissions I cannot create new folder : mkdir: cannot create directory `/home': Permission denied cp: cannot create regular file `/home/Vincent/.inputrc': No such file or direry bash: cd: /home/Vincent: No such file or directory Then you don't have permissions to write to that folder. It means I usually have to run my application using administrator rights but I don't like to do this. Cygwin seems to allow user to create folder inside its installation path so I would like to know how it's possible. Sorry my, is this question regarding Cygwin, or msys? Forget my question because it's not the right place here but my remark about README is related to cygwin. So I don't care but it wouldn't hurt to update your document. -- 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: File paths redirected to MSYS directory
Hi Nathan, On Mon, Nov 29, 2010 at 9:20 AM, Nathan Rose wrote: Thanks for your help. I have fixed the Windows path but Cygwin seems to be altering it when loading it in to its own $PATH environment variable. Compare below, my path as obtained from Windows cmd console and from Cygwin. Notice the line 'C:\cygwin\bin' in the first one (end of the second line) has been turned in to '/usr/bin' in the second one (end of the third line). Why would this be happening? Also, is it a problem that the first two entries in the Cygwin path are '/usr/...' rather than '/cygdrive/c/cygwin/usr/...' ? No, it is not a problem that the first two entries are /usr ... These are POSIX style paths which Cygwin uses. As it happens, /usr is the same directory on the disk as /cygdrive/c/cygwin/usr, but /usr is easier to type :) Cygwin creates a make-believe file system where everything is under one root directory called /. In reality, this is the Windows directory known as C:\cygwin. Everything that belongs to Cygwin lives under this directory and can be reached starting from the root. As a convenience to be able to access other drives and and also directories other than C:\cygwin, all the Windows drives are mounted under /cygdrive, so for example the Documents (My Documents) directory can be addressed as /cygdrive/c/Users/username/Documents. As to the difference between the Windows PATH and the Cygwin PATH. When a Cygwin process starts, it gets the Windows environment which contains Windows style directories. The Cygwin DLL (which is loaded into every Cygwin process) converts these into POSIX style (the paths starting from /cygdrive/c/WINDOWS/System32). Then, the command interpreter (probably bash) runs its own start-up scripts. My /etc/profile contains, among others: PATH=/usr/local/bin:/usr/bin:/bin:$PATH export PATH What this does is to set up the PATH with the directories needed for Cygwin at the front, and then the inherited PATH as a convenience (so Windows programs can be started from Cygwin prompts, e.g. Notepad). Windows: C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\SYSTEM32\Wbem;C:\Program Files\Novell\ ZENworks\;C:\Program Files\QuickTime\QTSystem\;C:\MinGW\bin;C:\cygwin\bin;C:\msy s\1.0\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Novell\GroupWise;C:\ Program Files\Putty;C:\GTK\2.0\bin;C:\Program Files\SSH Communications Security\ SSH Secure Shell;Z:.;Y:.; Cygwin: /usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/System32:/cygdrive/c/WINDOWS:/c ygdrive/c/WINDOWS/SYSTEM32/Wbem:/cygdrive/c/Program Files/Novell/ZENworks/:/cygd rive/c/Program Files/QuickTime/QTSystem/:/cygdrive/c/MinGW/bin:/usr/bin:/cygdriv e/c/msys/1.0/bin:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/c/Program F iles/Novell/GroupWise:/cygdrive/c/Program Files/Putty:/cygdrive/c/GTK/2.0/bin:/c ygdrive/c/Program Files/SSH Communications Security/SSH Secure Shell:Z:.:Y:. -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File paths redirected to MSYS directory
On 29 November 2010 08:20, Nathan Rose wrote: You're probably invoking MSYS's versions of vi and make. You can check that with the which command. Ensure that you do have the Cygwin versions of those installed, and that the Cygwin bin directory comes before MSYS's in the Cygwin PATH. To avoid such confusion, you might want to remove MSYS's bin directory from the global Windows path, assuming that's where it came from. Andy Thanks for your help. I have fixed the Windows path but Cygwin seems to be altering it when loading it in to its own $PATH environment variable. Compare below, my path as obtained from Windows cmd console and from Cygwin. Notice the line 'C:\cygwin\bin' in the first one (end of the second line) has been turned in to '/usr/bin' in the second one (end of the third line). Why would this be happening? Also, is it a problem that the first two entries in the Cygwin path are '/usr/...' rather than '/cygdrive/c/cygwin/usr/...' ? Windows: C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\SYSTEM32\Wbem;C:\Program Files\Novell\ ZENworks\;C:\Program Files\QuickTime\QTSystem\;C:\MinGW\bin;C:\cygwin\bin;C:\msy s\1.0\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Novell\GroupWise;C:\ Program Files\Putty;C:\GTK\2.0\bin;C:\Program Files\SSH Communications Security\ SSH Secure Shell;Z:.;Y:.; Cygwin: /usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/System32:/cygdrive/c/WINDOWS:/c ygdrive/c/WINDOWS/SYSTEM32/Wbem:/cygdrive/c/Program Files/Novell/ZENworks/:/cygd rive/c/Program Files/QuickTime/QTSystem/:/cygdrive/c/MinGW/bin:/usr/bin:/cygdriv e/c/msys/1.0/bin:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/c/Program F iles/Novell/GroupWise:/cygdrive/c/Program Files/Putty:/cygdrive/c/GTK/2.0/bin:/c ygdrive/c/Program Files/SSH Communications Security/SSH Secure Shell:Z:.:Y:. What Csaba said. Also, MSYS's bin directory does appear in there (/cygdrive/c/msys/1.0/bin), but Cygwin's is before it, so that's fine. Hence, as mentioned before, you need to check whether you do actually have Cygwin's vi and make installed, e.g. using the 'which' command. For further installation questions, please provide the cygcheck output requested at http://cygwin.com/problems.html. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: find -execdir executes in wrong dir
I was wondering how a fix for the below can be obtained as soon as
it's available? The current implementation of find's -execdir has all
our scripts that use cygwin halted.
Thanks,
Peter
-
www.pdanford.com
On Nov 22 13:13, Dirk Fassbender wrote:
The behaviour of find -execdir is documented in the info pages.
From the info page:
-- Action: -execdir command ;
Execute COMMAND; true if zero status is returned. `find' takes
all arguments after `-execdir' to be part of the command until an
argument consisting of `;' is reached. It replaces the string
`{}' by the current file name being processed everywhere it occurs
in the command. Both of these constructions need to be escaped
(with a `\') or quoted to protect them from expansion by the
shell. The command is executed in the directory in which `find'
was run.
So
C:\cygwin\bin\find . -name file.txt -type f -execdir pwd ';'
execute the pwd in the current directory and do not change directories.
The man page claims something different, or the wording in the info
file is ambiguous:
-execdir command ;
-execdir command {} +
Like -exec, but the specified command is run from the subdirecâ
tory containing the matched file, which is not normally the
directory in which you started find. This a much more secure
method for invoking commands, [etc]
Here's what happens with find 3.5.8:
$ find . -name foobar -execdir pwd \; -execdir echo '{}' \;
/home/corinna/tmp/abc
./foobar
/home/corinna/tmp/DOS
./foobar
/home/corinna/tmp/foo
./foobar
/home/corinna/tmp
./foobar
And here what happens with find 3.5.9:
$ find . -name foobar -execdir pwd \; -execdir echo '{}' \;
/home/corinna/tmp/abc
./foobar
/home/corinna/tmp/abc
./foobar
/home/corinna/tmp/abc
./foobar
/home/corinna/tmp/abc
./foobar
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
1.7.7: sshd time skew
Hi, Could someone explain why the time differs when i log in using ssh versus typing date in a mintty window. Output from a mintty window: $ date; ssh localhost date; date Mon Nov 29 11:02:30 CUT 2010 gi...@localhost's password: Mon Nov 29 11:02:56 CUT 2010 Mon Nov 29 11:02:34 CUT 2010 I'm running on a Windows Server 2008 and cygwin dll 1.7.7. Thanks Gifen -- 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
tcsh out of memory and core dump
I can readily reproduce a tcsh error Out of memory, however the timing is variable. In my actual application the time to failure varies from seconds to hours. I have a test case that seems to be able to reproduce the error. The symptom of the error is a message like: 188 ./test2 189 ./test2 190 ./test2 191 tcsh current memory allocation: free: 0 119 52 25 29 23 1730200 20000000000000 000 used: 09 204 167 51 33 1931122 14300000000000 000 Total in use: 788560, total free: 100272 Allocated memory from 0xab to 0x. Real top at 0xb89000 nbytes=32784: Out of memory Abort (core dumped) 192 ./test2 193 ./test2 194 ./test2 195 ./test2 The test case is run by the command ./test1. I have run it from a tcsh, but I don't know that this is required to generate the failure. Cygwin Configuration Diagnostics Current System Time: Mon Nov 29 05:37:13 2010 Windows 7 Home Premium Ver 6.1 Build 7600 Running under WOW64 on AMD64 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Program Files\Common Files\Microsoft Shared\Windows Live C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Program Files\Broadcom\Broadcom 802.11\Driver C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\ C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\ C:\Program Files (x86)\Common Files\Roxio Shared\12.0\DLLShared\ C:\Program Files (x86)\Windows Live\Shared C:\Program Files\TortoiseSVN\bin Output from C:\cygwin\bin\id.exe UID: 1000(strabert) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) 1001(HomeUsers) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'strabert' PWD = '/home/strabert' HOME = '/home/strabert' HOMEPATH = '\Users\strabert' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\strabert\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'becky' OnlineServices = 'Online Services' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 37 Stepping 5, GenuineIntel' WINDIR = 'C:\Windows' Platform = 'MCD' PUBLIC = 'C:\Users\Public' OLDPWD = '/usr/bin' USERDOMAIN = 'becky' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' PCBRAND = 'Pavilion' USERNAME = 'strabert' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'C.UTF-8' USERPROFILE = 'C:\Users\strabert' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\BECKY' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\strabert\AppData\Local' !C: = 'C:\cygwin\bin' ProgramData = 'C:\ProgramData' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PRINTER = 'Microsoft XPS Document Writer' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '2505' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '4' COMPUTERNAME = 'BECKY' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS459216Mb 15% CP CS UN PA FC d: hd NTFS 17418Mb 86% CP CS UN PA FC RECOVERY e: cd N/AN/A C:\cygwin/ system binary,auto C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,auto Found: C:\cygwin\bin\awk Found: C:\cygwin\bin\awk - C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\cpp.exe -
/etc/profile optimization and correctness
Starting a login shell on my system takes a painfully long time, mostly
because fork() is pretty slow on WOW6432 systems. I've taken a look at
the shell initialization routines and identified some potential savings:
- Can't we use USERNAME to set USER instead of running `id -un`?
- Move the /tmp chmod to the user-home-directory-doesn't-exist-case, or
better yet, get rid of it altogether and move /tmp permission setting to
install scripts
- Detect the current shell by examining BASH_VERSION, ZSH_VERSION, and
so on, not by forking for the echo|tr|sed pipeline.
- Use this code to run the profile.d scripts:
saved_LC_COLLATE=$LC_COLLATE
LC_COLLATE=C
for file in /etc/profile.d/*.{sh,zsh}; do
LC_COLLATE=$saved_LC_COLLATE
test -a $file . $file
done
unset saved_LC_COLLATE
- The default /etc/profile exports PS1. Please don't do that: it causes
weird issues with Emacs tramp; it causes other shells that interpret PS1
differently (like zsh) to do odd things; and it uses up precious
environment-block space. Better to set PS1 in bashrc.
- There's a useless uname -s invocation: since Cygwin doesn't run on
Windows 9x anymore (and good riddance!), the first branch of the
conditional is always taken. (Saves two forks.)
- Replace the invocation of regtool with a direct read from
/proc/registry. That is, instead of
# Three forks
PRINTER=`regtool -q get '\user\Software\Microsoft\Windows
NT\CurrentVersion\Windows\Device' | sed 's/,.*$//'`
use
# Zero forks
read -r PRINTER
'/proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows
NT/CurrentVersion/Windows/Device'
export PRINTER=${PRINTER%%,*}
I've modified my own /etc/profile. It ends up being an order of
magnitude faster than the stock version:
dan...@xyzzy ~
$ time . /etc/defaults/etc/profile
real0m1.012s
user0m0.075s
sys 0m0.318s
dan...@xyzzy ~
$ time . /etc/profile
real0m0.104s
user0m0.015s
sys 0m0.015s
signature.asc
Description: OpenPGP digital signature
recursive scp and directory permissions
When I use scp -r for recursive copy from Win7 to a remote XP machine, the properties for the new directory show the message The permissions on ... are incorrectly ordered ... This is for a simple test case. For an attempted network backup, the process hung up, and I could get access to the files on the remote machine only after tinkering with the permissions. Google revealed problems with directory permissions using Cygwin with scp -r, but not in the past few years. What is the current status? Is there a simple workaround for recursive copy? I tried tar | ssh but again got the message The permissions ... are incorrectly ordered. -- 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: File paths redirected to MSYS directory
On Mon, Nov 29, 2010 at 09:51:19AM +, Andy Koppe wrote: What Csaba said. Also, MSYS's bin directory does appear in there (/cygdrive/c/msys/1.0/bin), but Cygwin's is before it, so that's fine. Hence, as mentioned before, you need to check whether you do actually have Cygwin's vi and make installed, e.g. using the 'which' command. Fine is a relative term here. Mixing Cygwin with some other application which provides similar utilities is bound to create confusion. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /etc/profile optimization and correctness
On Mon, Nov 29, 2010 at 05:22:56AM -0800, Daniel Colascione wrote:
Starting a login shell on my system takes a painfully long time, mostly
because fork() is pretty slow on WOW6432 systems. I've taken a look at
the shell initialization routines and identified some potential savings:
- Can't we use USERNAME to set USER instead of running `id -un`?
- Move the /tmp chmod to the user-home-directory-doesn't-exist-case, or
better yet, get rid of it altogether and move /tmp permission setting to
install scripts
- Detect the current shell by examining BASH_VERSION, ZSH_VERSION, and
so on, not by forking for the echo|tr|sed pipeline.
- Use this code to run the profile.d scripts:
saved_LC_COLLATE=$LC_COLLATE
LC_COLLATE=C
for file in /etc/profile.d/*.{sh,zsh}; do
LC_COLLATE=$saved_LC_COLLATE
test -a $file . $file
done
unset saved_LC_COLLATE
- The default /etc/profile exports PS1. Please don't do that: it causes
weird issues with Emacs tramp; it causes other shells that interpret PS1
differently (like zsh) to do odd things; and it uses up precious
environment-block space. Better to set PS1 in bashrc.
- There's a useless uname -s invocation: since Cygwin doesn't run on
Windows 9x anymore (and good riddance!), the first branch of the
conditional is always taken. (Saves two forks.)
- Replace the invocation of regtool with a direct read from
/proc/registry. That is, instead of
# Three forks
PRINTER=`regtool -q get '\user\Software\Microsoft\Windows
NT\CurrentVersion\Windows\Device' | sed 's/,.*$//'`
use
# Zero forks
read -r PRINTER
'/proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows
NT/CurrentVersion/Windows/Device'
export PRINTER=${PRINTER%%,*}
I've modified my own /etc/profile. It ends up being an order of
magnitude faster than the stock version:
dan...@xyzzy ~
$ time . /etc/defaults/etc/profile
real 0m1.012s
user 0m0.075s
sys 0m0.318s
dan...@xyzzy ~
$ time . /etc/profile
real 0m0.104s
user 0m0.015s
sys 0m0.015s
I'm already working in some changes in base-files to include some
bugfixes, and hopefully improve start-up performance by reorganizing how
things are done now. I'll check your proposals.
One thing: we need to set at least a minimum PS1 in /etc/profile,
because every shell (except tcsh and zsh) fallback to that setting in
case there are no ~/.${SHELL}rc and friends. And also because not
everybody uses bash (even though it is the default one) :)
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: /etc/profile optimization and correctness
On 11/29/2010 8:22 AM, Daniel Colascione wrote: Starting a login shell on my system takes a painfully long time, mostly because fork() is pretty slow on WOW6432 systems. I've taken a look at the shell initialization routines and identified some potential savings: - Can't we use USERNAME to set USER instead of running `id -un`? You can't rely on USERNAME. For example, if I login via ssh using pubkey authentication, USERNAME is set to SYSTEM on my machine. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.x: m4 does not show any reaction
Am 26.11.2010 09:32, schrieb Corinna Vinschen: There's an older Cygwin DLL in the path somewhere. You should try to find and remove it. True. I've found it in c:\cygwin\bin\cygwin1.dll and in parallel c:\cygwin\bin\cygwin1.dll.new - I renamed the current one to *.old and the .new to cygwin1.dll. m4.exe works perfectly now. Many thanks. -- 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: tcsh out of memory and core dump
On Nov 29 05:58, tsteven4 wrote: I can readily reproduce a tcsh error Out of memory, however the timing is variable. In my actual application the time to failure varies from seconds to hours. I have a test case that seems to be able to reproduce the error. The symptom of the error is a message like: 188 ./test2 189 ./test2 190 ./test2 191 tcsh current memory allocation: free: 0 119 52 25 29 23 1730200 20000000000000 000 used: 09 204 167 51 33 1931122 14300000000000 000 Total in use: 788560, total free: 100272 Allocated memory from 0xab to 0x. Real top at 0xb89000 nbytes=32784: Out of memory Abort (core dumped) 192 ./test2 193 ./test2 194 ./test2 195 ./test2 Thanks for the testcase! It helped me to track down a memory leak in Cygwin which occurs on each dup/dup2/dup3 call on a tty. This is done very often in tcsh and thus affects long-running scripts quite heavily. I applied a patch to CVS. Please test the next Cygwin developer snapshot from http://cygwin.com/snapshots/, which will contain the fix. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: /etc/profile optimization and correctness
On 11/29/2010 9:29 AM, David Sastre wrote:
I'm already working in some changes in base-files to include some
bugfixes, and hopefully improve start-up performance by reorganizing how
things are done now. I'll check your proposals.
Good.
One thing: we need to set at least a minimum PS1 in /etc/profile,
because every shell (except tcsh and zsh) fallback to that setting in
case there are no ~/.${SHELL}rc and friends. And also because not
everybody uses bash (even though it is the default one) :)
Set, fine. Export, no --- OS X and RHEL manage to avoid exporting PS1
and the world doesn't fall apart. Cygwin doesn't need to do it either.
--
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: /etc/profile optimization and correctness
On 11/29/2010 10:39 AM, Ken Brown wrote: On 11/29/2010 8:22 AM, Daniel Colascione wrote: Starting a login shell on my system takes a painfully long time, mostly because fork() is pretty slow on WOW6432 systems. I've taken a look at the shell initialization routines and identified some potential savings: - Can't we use USERNAME to set USER instead of running `id -un`? You can't rely on USERNAME. For example, if I login via ssh using pubkey authentication, USERNAME is set to SYSTEM on my machine. Works fine for me. -- 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: /etc/profile optimization and correctness
On Mon, Nov 29, 2010 at 01:23:01PM -0800, Daniel Colascione wrote: On 11/29/2010 10:39 AM, Ken Brown wrote: On 11/29/2010 8:22 AM, Daniel Colascione wrote: Starting a login shell on my system takes a painfully long time, mostly because fork() is pretty slow on WOW6432 systems. I've taken a look at the shell initialization routines and identified some potential savings: - Can't we use USERNAME to set USER instead of running `id -un`? You can't rely on USERNAME. For example, if I login via ssh using pubkey authentication, USERNAME is set to SYSTEM on my machine. Works fine for me. Nevertheless, making /etc/profile rely on a user-settable environment variable is still a bad idea. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: 1.7.7: Open BASH Shell Here goes to wrong location
I have determined that modifying the registry entry to: [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe -e /bin/xhere /bin/bash.exe \%L\ [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - e /bin/xhere /bin/bash.exe \%L\ ...fixes the problem. But this is lame. I know Windows explorer is supposed to pass the location to minty, so why do I need to jump through these hoops? Does anybody have any understanding of what is going on? -Kevin -Original Message- Behalf Of Roe, Kevin L. Sent: Monday, November 29, 2010 11:12 AM Subject: 1.7.7: Open BASH Shell Here goes to wrong location I have set up a registry entry: [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - This creates the BASH Shell here links in Explorer, but there is a problem. When I try to use it, it goes to the wrong location. When I use it in the directory tree side (left side) it always goes to the /cygdrive/c/Windows/system32 directory When I use it in the Directory side (right side) it always goes to one level below what I am selecting. Any ideas? Kevin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.7: Open BASH Shell Here goes to wrong location
Roe, Kevin L. wrote: I know Windows explorer is supposed to pass the location to minty, so why do I need to jump through these hoops? I'm curious. Why are you editing the registry by hand instead of using chere? http://code.google.com/p/mintty/wiki/Tips#Creating_a_folder_context_menu _entry_for_mintty -Original Message- Behalf Of Roe, Kevin L. Sent: Monday, November 29, 2010 11:12 AM Subject: 1.7.7: Open BASH Shell Here goes to wrong location I have set up a registry entry: [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - This creates the BASH Shell here links in Explorer, but there is a problem. When I try to use it, it goes to the wrong location. When I use it in the directory tree side (left side) it always goes to the /cygdrive/c/Windows/system32 directory When I use it in the Directory side (right side) it always goes to one level below what I am selecting. Any ideas? Kevin -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: 1.7.7: Open BASH Shell Here goes to wrong location
Well, you may have noticed that my registry entries look remarkably like what chere produces. I used chere -i -p -c -t minty to find my working solution (with the hoops). I built my BASH shell here context menu before chere existed. I based it on the cmd shell here powertoy. It started out being rxvt, but I converted it to minty when I learned of it. My original version @=C:\\cygwin\\bin\\mintty.exe - used to work, but now I have to use the chere version @=C:\\cygwin\\bin\\mintty.exe -e /bin/xhere /bin/bash.exe \%L\ The new version seems very long winded. I'm just trying to understand why the simple version no longer works. -Kevin -Original Message- Behalf Of Matt Seitz (matseitz) Sent: Monday, November 29, 2010 3:47 PM Subject: Re: 1.7.7: Open BASH Shell Here goes to wrong location Roe, Kevin L. wrote: I know Windows explorer is supposed to pass the location to minty, so why do I need to jump through these hoops? I'm curious. Why are you editing the registry by hand instead of using chere? http://code.google.com/p/mintty/wiki/Tips#Creating_a_folder_context_men u _entry_for_mintty -Original Message- Behalf Of Roe, Kevin L. Sent: Monday, November 29, 2010 11:12 AM Subject: 1.7.7: Open BASH Shell Here goes to wrong location I have set up a registry entry: [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - This creates the BASH Shell here links in Explorer, but there is a problem. When I try to use it, it goes to the wrong location. When I use it in the directory tree side (left side) it always goes to the /cygdrive/c/Windows/system32 directory When I use it in the Directory side (right side) it always goes to one level below what I am selecting. Any ideas? Kevin -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File paths redirected to MSYS directory
What Csaba said. Also, MSYS's bin directory does appear in there (/cygdrive/c/msys/1.0/bin), but Cygwin's is before it, so that's fine. Hence, as mentioned before, you need to check whether you do actually have Cygwin's vi and make installed, e.g. using the 'which' command. For further installation questions, please provide the cygcheck output requested at http://cygwin.com/problems.html. Andy Now I feel a bit silly for not having thought of that myself. That's precisely what the problem was - there was no vi or make program installed, which I realised when I removed MSYS from the path and tried 'which' again. I've installed both packages and it's working fine now. Thanks, everyone, for your help! Nathan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.7: Open BASH Shell Here goes to wrong location
On 29 November 2010 19:11, Roe, Kevin L. wrote: I have set up a registry entry: [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Directory\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt] @=Open BASH Shell Here [HKEY_CLASSES_ROOT\Drive\shell\bashrxvt\command] @=C:\\cygwin\\bin\\mintty.exe - This creates the BASH Shell here links in Explorer, but there is a problem. When I try to use it, it goes to the wrong location. When I use it in the directory tree side (left side) it always goes to the /cygdrive/c/Windows/system32 directory When I use it in the Directory side (right side) it always goes to one level below what I am selecting. 'mintty -' invokes your shell as a login shell. The default /etc/profile will cd to your home directory, but presumably you've changed that, as that's not what you're seeing. Hence you'll end up in whatever directory Explorer decided to start mintty, so it seems Explorer doesn't necessarily set the current directory to the one you're looking at. Apparently that could be due to a shell extension, according to this: http://blogs.msdn.com/b/oldnewthing/archive/2010/11/09/10087919.aspx Any ideas? As Matt said: use 'chere'. That's what it's for. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
