Re: behaviour of "for (( exp1; exp2; exp3 )); do COMMANDS; done"
Stuart Brady <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Tue, 27 May 2003 13:07:18 +0100: > On Tue, May 27, 2003 at 12:42:21PM +0100, Sam Edge wrote: > > Make sure that if your script uses Bash-specific features, it starts > > with #!/bin/bash and not with #!/bin/sh. That way it'll work anywhere. > > You've made the assumption that bash is always in /bin. I've seen it > in /bin, /usr/bin, /usr/local/bin, /usr/contrib/bin, and /opt/bash/bin. > ~/bin would be another likely place for it. I just _knew_ I shouldn't have said "anywhere." ;-) Unfortunately this is a general weakness in the "#!/" syntax. (OT) Does anyone know if any of the common shells, when they see "#!/bin/" at the front of a script, try a $PATH search for an "" executable if they can't find "/bin/"? This would seem like a good idea to me. Regards, -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: behaviour of "for (( exp1; exp2; exp3 )); do COMMANDS; done"
Randall R Schulz <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Wed, 28 May 2003 06:30:47 -0700: > The interpretation of #! lines is in the kernel (or, hereabout, > Cygwin1.dll, a kernel by any other name), just as the kernel would how > to handle a binary executable by examining its header. * man execve * Well, well. I knew that some unices had to be doing this because they allowed suid scripts. But I thought the behaviour had been phased out of newer versions. (Because Linux and the like don't allow suid scripts, I assumed that this whole script-handling behaviour had been moved out of the kernel.) I learn something new every day. Thanks. :-) Regards, -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: behaviour of "for (( exp1; exp2; exp3 )); do COMMANDS; done"
Harald Maier <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>
in gmane.os.cygwin on Wed, 28 May 2003 13:28:43 +0200:
> > (OT) Does anyone know if any of the common shells, when they see
> > "#!/bin/" at the front of a script, try a $PATH search for an
> > "" executable if they can't find "/bin/"? This would seem like
> > a good idea to me.
> Some people are using the env program to use the PATH environment:
> #! /usr/bin/env perl
> BEGIN { $^W = 1 }
Erm ... doesn't this just duplicate the problem? How can you guarantee
that "env" is always in /usr/bin?
It's also pretty inefficient, isn't it?
Ho hum ... off topic thread alert! Mea culpa. ;-)
Regards,
--
Sam Edge
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: behaviour of "for (( exp1; exp2; exp3 )); do COMMANDS; done"
Harald Maier <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>
in gmane.os.cygwin on Thu, 29 May 2003 11:32:23 +0200:
> >> Some people are using the env program to use the PATH environment:
> >> #! /usr/bin/env perl
> >> BEGIN { $^W = 1 }
> > Erm ... doesn't this just duplicate the problem? How can you guarantee
> > that "env" is always in /usr/bin?
> > It's also pretty inefficient, isn't it?
> It gives you the freedom to start different interpreters with the same
> script. E.g. perl-5.6 or perl-5.8. This might be interesting for
> testing purposes. What are you looking for?
I was looking for portability of scripts where the script interpreter
may not be in the same location e.g. bash is /bin/bash on Linux and
Cygwin but may be /usr/bin/bash or /usr/local/bin/bash or even
$HOME/bin/bash on another system.
The obvious idea would be for the code that handles "#!/bin/" to
look in the $PATH if doesn't exist in /bin - but there are
security concerns with this approach, of course.
Anyway, the whole discussion is not Cygwin specific. If anyone wants
to discuss it further then e-mail me direct. (You'll have to make my
e-mail address less sleepy to do so.)
Regards,
--
Sam Edge
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: activating a dial-up connection from cygwin
"Rob" <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Fri, 25 Jul 2003 10:01:28 -0400: > Hello, > > I was wondering if there was any way to activate an existing windows 2000 > dial-up connection from the cygwin command line. > > The reason I want to know is because I have a shell script that > automatically backs up files to a remote computer (which is only accessible > through a vpn connection). Since I don't want to maintain the VPN > connection all the time, I need a way to start it up (and possibly shut it > down) from the command line. Try typing rasdial /help from a command line. It's a built-in in NT, 2k and (I think) XP and works fine for me from CMD.EXE or bash. There's a freeware (or perhaps shareware) version available for 9x/Me as well. You'll have to Google for that. Regards, -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache problems gone with 1.50
Stipe Tolj <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Wed, 30 Jul 2003 00:51:18 +0200: Andrew DeFaria <[EMAIL PROTECTED]>: > > This is good to hear. Perhaps I will switch from Apache for Windows -> > > Apache under Cygwin. Only problem is I also trying to move my web site > > over to a Linux box instead - which makes this all kinda moot. However I > > do have a friend who wishes to host his web site on a Windows box and I > > am contemplating using Cygwin for most services. If Apache under Cygwin > > works well with 1.5.0 then perhaps I'll just go that way. I wonder if > > anybody has measured the speed difference between Apache for Windows and > > Apache under Cygwin... > I did some time ago. It was almost 35-40% slower on Apache for Cygwin > then his native (win32) counterpart. > Plain html file requests, no php or any other "magic". Andrew might want to consider compiling Cygwin-Apache with the native Winsock option. This way it still lives in the Cygwin file system space so has the POSIX/Linux style configuration files but bypasses the Cygwin Berkeley->Winsock socket API translation. Apparently this helps. (But I suspect the majority of the performance difference Stipe has found is the use of threads in the native Windows version against forking child processes in the *X versions which is a more expensive operation.) Regards -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win2k and cygwin memory leak
Rolf Campbell <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Thu, 07 Aug 2003 17:44:08 -0400: > Does > windows claim to free all memory allocated by a process when it exits? It does, even on unexpected terminations. (Seg-faults and the like.) > What about cygwin shared memory? Unlike System V, Windows shared memory is transient. Once all handles that reference it are closed Windows deallocates it. And Windows closes all open handles for a process when the process exits, even if this was caused by an unexpected termination. So the Cygwin shared memory is automatically deallocated once the last Cygwin process exits, irrespective of any bugs (memory leaks) in Cygwin. Again, /supposedly/. ;-) Regards, -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin & MinGW
"Alex Vinokur" <[EMAIL PROTECTED]> wrote in <003501c26a36$6eecdbf0$2c2296d4@5at8s8cqeex4qhi> in gmane.os.cygwin on Wed, 2 Oct 2002 19:09:10 +0200: > But if I have Cygwin : when is it worth using the Mingw32 (not Cygwin) interface? > Any example ? ... when you want to compile a program that will work on Windows machines that don't have Cygwin installed. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ping on cygwin?
Tino Lange <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Mon, 13 Jan 2003 18:36:45 +0100: > Thanks! I read it once again and hence I like to (try to) contribute - > see below. > > I learned a lot about raw icmp sockets and why only root is allowed to > open them - making ping a setuid program. If you do write a better ping for Windows - whether native or Cygwin - you can use raw sockets and construct your own ICMP datagrams but on NT/2k/XP-Pro this will only run if you have elevated privileges, just as on UNIX-like systems. Because there's no SUID feature available in Windows or in Cygwin (yet!) this is something of a problem. In case you're not aware, the Microsoft ping.exe and tracert.exe programs use a system library called icmp.dll which provides system calls that will send and receive ICMP Echo datagrams without needing extra privileges. This might be useful for your version. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm/htm/_wcesdk_internet_control_message_protocol__icmp_.asp (Don't worry that this is under the Windows CE section, by the way. It applies to NT/2k/XP too.) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Advocacy
Igor wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Mon, 3 Mar 2003 16:49:05 -0500 (EST): > I believe the complaints were mostly about the *size* of the disclaimer, > not about its content. The content is reasonably standard and pretty > redundant, IMO. Which is why I proposed a way for people to allow > filtering it out (by including, say, an "--IGNORE-LONG-DISCLAIMER-BELOW--" > line in their signature). "Redundant" is hardly the word. "Ludicrous" is perhaps better. Last time I checked, it's not possible to force a non-disclosure agreement or any other form of contract on someone just by having them read it. Some sort of verbal or written consent is required ... at least in the UK. Thanks Nomura International plc, but since your legal department doesn't understand this, I'll avoid any business dealings with you if I can. Right. This is deeply OT for [EMAIL PROTECTED] so I'll shut up again. -- Sam Edge This e-mail is intended for you. By reading it you have agreed to give me all assets in your posession and the labour of yourself and your descendants in perpetuity. And a date with your sister. So there. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash shell extension ?
> [HKEY_CLASSES_ROOT\Folder\shell\Bash Prompt] > [HKEY_CLASSES_ROOT\Folder\shell\Bash Prompt\command] > @="bash.exe -c 'cd \"%1\"; exec bash'" > It seems you might also have to mount the drives you want to use. Use single quotes for the cd command so that if the Windows shell substitutes something ending in backslash for %1 it doesn't escape the close quote. Use the Directory key instead of the Folder one. (The difference being that Folder includes fictions of the Windows shell namespace that don't correspond to real directories.) To allow invocation of a prompt via the context menu of a drive icon apply the command to the Drive key as well as the Directory one. Finally, by including a default value for the command, you can add an underline shortcut to the context menu. (Most of this is really nothing to do with cygwin - it's all standard Windows stuff.) REGEDIT4 [HKEY_CLASSES_ROOT\Directory\shell\BashHere] @="&Bash Prompt Here" [HKEY_CLASSES_ROOT\Directory\shell\BashHere\command] @="c:\\cygwin\\bin\\bash.exe -c \"cd '%1' ; exec /bin/bash\"" [HKEY_CLASSES_ROOT\Drive\shell\BashHere] @="&Bash Prompt Here" [HKEY_CLASSES_ROOT\Drive\shell\BashHere\command] @="c:\\cygwin\\bin\\bash.exe -c \"cd '%1' ; exec /bin/bash\"" -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash shell extension ?
"Adam" <[EMAIL PROTECTED]> wrote; > [HKEY_CLASSES_ROOT\Directory\shell\Bash\command] > @="bash.exe -c 'cd \"%1\"; exec /bin/bash.exe'" As I said, if you use double-quotes around the %1 then it won't work for Drive because the trailing backslash will escape the closing quote. You may also get other problems with Windows backslashes as well. > Using this it works fine, with the exception of grossly truncating the long > folder names .. If this could be fixed, I would be very happy .. :) > -Adam > > P.S. The changes that I made as per your suggestion, I did through the registry > directly (not via a .reg file) .. If this possible caused some problems, let me > know .. Perhaps you could copy & paste the exact key that is in your registry > to the mailing list? The text I included was copied straight from a .REG file and could be copied straight back in as long as the file has MS-DOS line endings and includes the REGEDIT4 header line. (When entering such a thing directly in regedit you have to remember not to include all the escape characters.) Anyway, a copy is available at http://homepage.ntlworld.com/sam.edge/temp/bash.prompt.reg for download. Once you've got it, open it in Notepad to make sure it's come across with CRLF line endings. I've tried this on 9x and NT series OSes and it works for both for both directories and drives. Chris January's idea about creating a batch file and starting bash from this - possibly using cygpath to massage the passed pathname - would certainly make the line in the registry simpler but results in an extra CMD.EXE (or COMMAND.COM) process loading into memory and waiting around until the bash prompt exits. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash shell extension ?
"Adam" <[EMAIL PROTECTED]> wrote; > Ah-hah! This reg file works perfectly! Thanks Sam! LOL. Glad I could help. Unfortunately there are still problems. First off, you don't get the menu item for network shares in the Network Neighbourhood so you can't get a bash prompt in the root of a share. Secondly, although you do get the prompt for folders within shares, the command doesn't select the correct directory because bash is reducing the '\\' at the front of the UNC path passed by Windows in the substitution for %1 to a single backslash even when enclosed in single quotes. It might be time to think of a little utility that takes a Windows path as its first argument without converting any shell escapes in it, converts that to UNIX à la cygpath, chdirs to this and then execs its second argument with subsequent ones as the rest of the argv. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: crypt command
> Its very easy to knock your self up a crypt. Perl has a crypt function so it > should be very easy to create a crypt that takes the plain text password on > stdin. It would also very easy to do in 'C' (although it appears that mcrypt > will do the job). mcrypt has (old) crypt compatibility but if that isn't a requirement then the openssl package can be made to do much the same thing very easily. openssl des3 -salt -pass pass:X ciphertext openssl des3 -d -pass pass:X plaintext You can choose a different cipher if you like - they're all better than the crippled Enigma one that crypt used to use - although a passphrase better than a single "X" character is probably a good idea. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: True Static Linking
> (1) Is there a "-static" switch that statically links in cygwin1.dll? > (2) If not, how else can I solve this problem? I'm fairly new to Cygwin but from what I've picked up there is no static version of the cygwin library available either binary or source. This is a deliberate policy to try to ensure that all running Cygwin processes have the same version loaded and are all using the same shared memory and other kernel objects that are required to simulate the UNIX/POSIX API on top of the Win32 one. If your program really needs things like fork() or native Berkley sockets you could get the source for Cygwin and patch it to generate your own static version. I've no idea how difficult this might be and maintaining it with newer versions would be a headache. (It may be that a DLL is required by the Win32 architecture for some of the features.) I doubt whether a simple stand-alone executable needs this. The first thing to do is to try the "-mno-cygwin" switch on gcc as well as making everything else statically linked. You might get away with this providing you're not relying on Cygwin-specific API calls or C++ standard template libraries. (Make sure you've used SETUP.EXE to install the mingw-runtime and w32api packages first.) If that's not enough, you can go to http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html to add the additional C++ STL. This has instructions for ensuring that you get what you need in a painless manner and can create native Win32 applications with the Cygwin GCC tool chain and all the other nice Cygwin (The other approach is to avoid using Cygwin as the development environment and to download the MinGW Win32-native GCC tols and libraries from http://www.mingw.org/, although this shouldn't be needed if you've configued everything correctly in Cygwin.) MinGW relies on the Micrsoft MSVCRTx.DLL run-time libraries but these are pretty much universal. There is in fact no such thing as completely static linkage under Windows since you always end up dynamically linking to SYSTEM32, USER32, GDI32 and/or other "universal" Win32 system DLLs. The VC runtime are pretty much in this category. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: will bash honor the suid bit or not?
> And you were right to guess that I already set ntsec in CYGWIN - it was my > first move. That, and to put the definition in the systems env. vars, so > other users who log in without Administrator privilege can't change it. I also set the CYGWIN environment in the "system variables" section of the NT configuration simply so that I can run Cygwin executables under any account without having to worry about it. However, this doesn't prevent ordinary users from changing its value prior to running Cygwin programs. Open an NT command prompt (CMD.EXE), type "SET CYGWIN=" and then "bash" and you'll see. > I am apparently ignorant of how to handle a case like this on NT/2000, nor > do I even know where to look. This problem must be solved for many uses > already. I would think that a great many services have this same problem. > It's an exceptionally common need to have a non-privileged user run a > program and get privileged results. The way it's normally done on NT is by installing a service - a special type of application that runs under the NT Service Manager susbsystem. (This is designed for processes that run independently of interactive users. It's used to implement the equivalent of UNIX daemon processes and other "system" facilities.) The service runs as SYSTEM or some other priveleged account and user processes use IPC to access its facilities in a controlled manner. > From where I sit, it sure looks like this problem should be solved for the > BASH shell. Under UNIX-like systems it's not bash that modifies the UID/GID of the created process but the operating system when asked to exec() a file with the appropriate suid/sgid bit set. Non-superuser processes can't call setXid() with an ID other than one of their own anyway. If they try, the call fails with errno == EPERM. (Otherwise any user could write a program that runs with the priveleges of any other!) > Perhaps it should become a service? I dunno! LOL. It's certainly not a good idea to start making major architectural changes in the shell program! > It'd be great to hear from more of you: Anyone else care to confirm > Larry's suggestion that giving privileges to users is the solution in this > case? If it's a security application then no. A better solution for NT would be to split the program into a client application and a non-Cygwin-based server service and have them communicate via whatever IPC mechanism with which you're happy. If you used TCP/IP sockets the client could remain a Cygwin application and you would be able to write a UNIX version of the server at some point too. An NT-specific solution might find RPC more appropriate though. You could write a standard UNIX-style daemon as a Cygwin application that uses sockets and install it as an NT service using cygrunsrv but this isn't a secure solution. The Cygwin documentation tells us that all Cygwin processes have access to shared memory resources and can compromise each others integrity. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is Cygwin legal under Windows XP?
You wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 21 Apr 2002 09:54:01 +0200: > > Microsoft's XP license agreement says, "Except as otherwise permitted > > by the NetMeeting, Remote Assistance, and Remote Desktop features > > described below, you may not use the Product to permit any Device to > > use, access, display, or run other executable software residing on the > > Workstation Computer, nor may you permit any Device to use, access, > > display, or run the Product or Product's user interface, unless the Device > > has a separate license for the Product." > > > That means using any software other than Microsoft's to view an XP > > desktop from Windows 2000 or any other operating system would violate > > the company's license agreement, in case you care. > > That is not correct, you can use whatever software you want to as long > as your 'Device' has a XP license. I've not read the full licence for XP but this passage taken alone would suggest that you need an extra licence for a monitor. After all, it's a separate device that displays the software and the UI. ;-) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is Cygwin legal under Windows XP?
You wrote in <3CC24897.10238.884BE175@localhost> in gmane.os.cygwin on Sun, 21 Apr 2002 05:05:27 -0500: > Or, Web servers which download Java, Javascript and ASP's. Download is okay - the code is running on the remote machine and needs a local (Java/.NET/ActiveX/WSH) licence to run there. I think you mean server-side DHTML. (Of course you can't run IIS on workstation versions of Win32 anyway.)The licence agreement does seem to suggest that you can't run CGI or PHP or other server-side code on Apache on XP Pro. Linux, anyone? ;-) > What concerns me is the the apparent stricture on any non-MS > remote access to one's own PC via sshd! I guess this would > even make PCAnywhere connections from a non-XP host illegal > w/o an additional XP license. Absolutely. From a straightforward reading it precludes peer-to-peer file sharing too. (Anyway, we're drifting off-topic so I'll stop.) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is Cygwin legal under Windows XP?
You wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 21 Apr 2002 20:34:16 +1000: > IIS runs just fine here (XP Pro). It also runs fine on NT 4 workstation > and 2000 workstation. Huh? I thought it'd only run on the "Server" version. That shows how much /I/ know! -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Getting Cygwin into a corporation..
You wrote in <01fd01c1ebba$23197580$0d76aec7@D4LHBR01> in gmane.os.cygwin on Wed, 24 Apr 2002 11:01:56 -0700: > In the company I work for they have outlawed all Unix > variants (Linux, Solaris, OSX) from certain networks. I > asked why Cygwin could not be installed and here is > some of the response I got back: > > Cygwin, in itself, is typically a harmless application. > > However, once installed, it does allow a user to invalidate > > the NT Security architecture; a user can then install cygwin > > ports without the NT administrators consent (including, of > > course, the cygwin DHCP port). > How should I respond to this? Cygwin1.dll and Cygwin applications makes calls to the OS API via kernel32.dll and the other system DLLs just like any other Windows application does. There's nothing they can do when run via a specific user account that any other Windows program couldn't do running from that same account. The shared memory used by cygwin1.dll is not protected so a malicious or buggy process in one context could crash a Cygwin process running in another by corrupting this data. But if you avoid installing any Cygwin programs as NT services then they'll all be running interactively in the context of the current user so they can't do anything that can't be done anyway. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Login as a different user?
You wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Thu, 25 Apr 2002 07:17:35 +0200: > I stumbled on this question too and foud out that using 'ssh -l > localhost' in combination with keychain works just fine. You don't even need keychain but of course you do need sshd running with enough privileges to create processes under other accounts. This is most easily done by running the sshd configuration script (/usr/bin/ssh-host-config) from an administrative login and allowing it to install sshd as an NT service. However, this opens up more potential avenues for your system to be accessed over the 'Net and you should consider using the ListenAddress directive to limit access to localhost. There's also a slight security risk just having any Cygwin process running with enhanced privileges. See the thread "Getting Cygwin into a corporation..." <01fd01c1ebba$23197580$0d76aec7@D4LHBR01> -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup 2.194.2.24: Bug (?) in downloading from internet
Daniele wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 28 Apr 2002 00:44:25 +0200 (MDT): > After dutifully reading the mailing list discussion on the subject, > I would like to point out that this behavior - redownloading uninstalled > packages - was absent > in previous versions of setup. In my humble opinion, the downloaded > packages and the installed packages should be treated independently by > setup for the simple reason that you may download a set of packages for > installing on multiple machines, and install a subset of it on the > downloading machine. In other words should be: > download from internet: compares repository with packages > install from internet: compares repository with installation > install from local: comapres packages with installation > that is, previous behaviour. Every version of setup.exe I've used exhibits this annoying behaviour but them I'm new here. I agree with Daniele. I install different subsets of the packages on several machines. I also like to keep a copy of the most up-to-date versions of packages that I don't currently use on any of them, in case I need them where I've no (or poor) access to the 'Net. Doing this is something of a headache and requires manual checking in the local package directory (now even more difficult because of its fragmented nature even when mitigated by clean_setup.pl - thanks Michael) and in the setup.exe list. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup 2.194.2.24: Bug (?) in downloading from internet
Robert Collins wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 28 Apr 2002 20:22:30 +1000: > > I agree with Daniele. I install different subsets of the > > packages on several machines. I also like to keep a copy of > > the most up-to-date versions of packages that I don't > > currently use on any of them, in case I need them where I've > > no (or poor) access to the 'Net. > > So use a mirroring tool! Setup.exe is -not- designed for this. Surely if setup.exe isn't designed with at least a nod to this way of working why does it have "download from Internet" and "install from local directory" options, instead of just instisting on connecting to a server every time? > If you > want a setup.ini parsing mirroring tool, take me up on my offer to help > someone leverage the setup.ini codebase to build a mirroring tool. Although I've not looked at it, setup.exe must already have most of the code required to operate in the way we'd like, surely? If you tell me the module name(s) for setup.exe and any documentation about setup.ini and the local and FTP/HTTP server directory structures I'd certainly be interested to download them from the CVS server and take a look. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup 2.194.2.24: Bug (?) in downloading from internet
Gary R. Van Sickle wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 28 Apr 2002 14:12:36 -0500: > What am I missing in all these posts? Didn't somebody post a while ago that if > you set your "Local Package Directory" to a network share and do "Install From > Internet", you get all the functionality people are wanting here? No. You can use the same local package directory to install on multiple machines very nicely. That aspect works fine. The problem is that when you do "download from Internet" the list tells you what you have installed in c:\cygwin on the machine where you're running setup.exe not what you've previously downloaded to the package directory. Add to this the lack of an option to skip previously downloaded packages when they're manually selected (or auto-selected by the dependency management) and it's a problem if you're using a single local package directory for several different machines that have different package sets installed. On a single machine where you download and immediately install only what'll be used locally it can still be a problem for those on slow, unreliable or time-limited connections. For example, many people in the UK use a 56kbps (or more usually around 45kbps) connection. Many unmetered ISP packages disconnect every two hours to prevent users hogging dial-in capacity they're not using. Downloading even a basic package with all its dependencies can run over this time limit so you can't use the "install from Internet" option. But when you try to use "download from Internet" and then re-start setup.exe after re-connecting it doesn't show you the packages you already have. Worse, when you select your package again it auto-selects all the dependencies and tries to download them all again and so will never complete because you'll keep hitting the disconnect timeout. What you have to do is have an Explorer window open looking at the package directory and manually go back and de-select all the ones you've already got after auto-select has added them. This is prone to error, especially if you've not used clean_setup.pl to flatten the structure between each download session. It's also annoying because it should be easy to automate into setup.exe itself. > Maybe we should dump the "Download" option entirely. Seems that all it serves > to do is confuse people that should really be looking at rsync. Please, no! Apart from the reason I give above, on my main machine here I always download first in my normal NT user account so I can continue to work while it's going on. I then log in as ADMINISTRATOR to install because I have the Cygwin directory hierarchy protected against write by normal users. That way I'm running with potentially dangerous privileges for as short a time as possible. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup 2.194.2.24: Bug (?) in downloading from internet
Charles Wilson wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 28 Apr 2002 18:07:12 -0400: > > Robert, you are a saint. > I am sick and tired of the whining about setup and downloads. > SETUP IS NOT A MIRRORING TOOL. LOL. No need to get your knickers in a twist! I was merely explaining the limitations of setup.exe to Gary. ;-) The problem with time limited slow connections is valid even when using it purely for local setup on a single machine i.e. when NOT using it as a mirroring tool. A simple checkbox option on the download-only page to skip pre-downloaded packages even if they're selected in the list would deal with that and I really don't see how this would compromise its function in any way, as long as it were off by default. Unless someone can give a good reason why it /would/ be a bad idea, I'll look at the code and see if I can write a version that has this. > In order to make this clear, I am in favor of completely removing the > download-only option, leaving just install-from-internet and > install-from-localdir. This will force the whiners to either shut up > and use a fscking mirroring tool, or help out: It will also stop users on slow time-limited connections from being able to use setup.exe at all unless they first use a conventional FTP/HTTP mirroring client and set up their own local FTP server to which to connect setup.exe. They then have to work out which parts of one of the current mirrors are required for their particular needs and download those packages. They'll also end up with two copies of everything on their hard discs. This is hardly a good way of increasing the Cygwin user/developer base! -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup 2.194.2.24: Bug (?) in downloading from internet
Christopher Faylor wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 28 Apr 2002 18:30:00 -0400: > If you're on the other end of a slow connection and are apt to be > disconnected every couple of hours, you will *never* be able to do a > complete install since the setup.exe will start from scratch every time > you reconnect. It doesn't matter if you chose "download from internet" or > not since setup.exe will only consider what's installed when considering > what to download. That just seems like a bug to me. Thanks. Even something like the XFree86 "basic" install can take a long time, let alone trying to install everything in one hit. Sometimes people forget that there are many still out there on creaky old dial-up connections. > If I have this right then even removing download from internet does not > eliminate this problem. No, it makes it worse. > So, I think the right answer to this is the standard one "patches > gratefully accepted". I'll look but I'm making no promises! ;-D -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup 2.194.2.24: Bug (?) in downloading from internet
Robert Collins wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Mon, 29 Apr 2002 17:47:16 +1000: > The *redownloading* is a bug, and will get fixed. Okay. Good. > The 'I want to mirror > > non-installed packages by using download' is not. Actually, the re-download fix would go 90% of the way to doing this anyway, since you could just reselect everything you want again and again and it'd eventually have the lot even on a slow link. > A 'normal' install - download and install - works fine, no problems. Read my and Christopher Faylor's posts especially <[EMAIL PROTECTED]> where we explain where for some people download and install with the current version of setup.exe does not work fine. Even a single package such as the XFree86-fnts one can be a trial on dial-up connections, taking the best part of an hour. A clean minimum install of the Cygwin environment takes about the same, I think. A model that didn't allow multiple download sessions before a single install one would effectively bar many dial-up users from installing Cygwin and/or XFree86 at all. The selective mirroring and local FTP server route would simply be too much hassle for many just to evaluate something. > A reference for this is > http://sources.redhat.com/ml/cygwin-apps/2001-11/msg00271.html. Ah. Exactly. :-) So is it worth my while looking at the code with an eye to providing a patch for this (specifically the checkbox option) or is it work in progress elsewhere? -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 'redownload' aka download again and setup.exe
Robert Collins wrote in <00bd01c1ef6f$590b36c0$0200a8c0@lifelesswks> in gmane.os.cygwin on Mon, 29 Apr 2002 21:16:44 +1000: > Please write back (to me or the list, your choice) whether you use the > DELIBERATE 'download again' functionality of setup.exe or not. I've not used it but then I've not been here long. Paranoid that I am, I'd be inclined to delete (or at least rename) a package I suspected before deliberately re-downloading it anyway. However, what with the fragmentation of the local package directory it might be useful to keep it as an option within setup.exe, unless doing so would leave the code too difficult to maintain than is worth while. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup 2.194.2.24: Bug (?) in downloading from internet
Robert Collins wrote in <016301c1ef7b$4d769f00$0200a8c0@lifelesswks> in gmane.os.cygwin on Mon, 29 Apr 2002 22:42:18 +1000: > Actually, the current functionality wil do the trick, as long as you > install what you have downloaded. Hmmm. I've just tried using "install from Internet" with bzip2, sharutils, unzip and zip, on a machine that doesn't have them installed and killing the connection after bzip2 has downloaded. When it says "download incomplete, try again" I say "No" and it attempts to do the install. I'm then getting "Can't open (null) for reading" errors during the attempted installation of sharutils (the sharutils sub-directory has been created but is empty) and a "installation incomplete" message box at the end but it /has/ installed bzip2. It's pretty ugly but it does seem to be working and if I reselect bzip2 when I try again it isn't attempting to download it again so yes, you could get there even on a slow link. (Not exactly good UI design though!) ;-) (While I'm here; BUG REPORT: When I get the "Download incomplete. Retry? Yes/No" message box in "install from Internet" mode and choose "No" without it then going on to install any packages I then get a final message box with "Download incomplete. Retry? Yes/No" again but only an "OK" button.) > http://www106.pair.com/rhp/free-software-ui.html. LOL. Yes. I think I can agree with most of this, especially the lack of UI consistency and the problems with debugging over-featured design. > Checkbox's, command line options, and 'special case code' and the > redownload itself are all kludges around fixing the key problem. I agree. The best solution is to make a bulletproof method of detecting whether the local copies are uncorrupted and to keep the UI uncluttered. But from the general tenor of the discussion at the beginning I was under the impression that there was some philosophical or technical reason why this wasn't appropriate. A manual option would therefore be the next best thing. Sorry if I got the wrong end of the stick. > The real solution is to positively identify corrupt archives and > transparently remove them (perhaps asking the user whether we should > delete, backup, or skip over the package). Yup. Agreed. Thesis, antithesis, synthesis! :-) Can I also suggest adding reget behaviour at some point, if it can be done reliably. Getting nine tenths of the way into a 15MB package when your line goes down is /very/ annoying! ;-( Finally, I stand by my wish to retain a separate download and installation invocation option to allow them to occur while logged on to NT/2k/XP with different permissions, again out of paranoia. Thanks. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Using a real mirroring tool...
Charles Wilson wrote in <[EMAIL PROTECTED]>
in gmane.os.cygwin on Mon, 29 Apr 2002 16:04:14 -0400:
> P.S. you might want to add --exclude *-src.tar.* to the option string,
> if you don't want the -src tarballs.
As I understand it you can also exclude the setup.hint and md5.sum
files if you're just populating a local package directory. They're
very small but every little helps and it reduces the clutter and can
save a few sectors on the local disc.
Or am I missing something? ("Again" do I hear from the chorus? Kindly
leave the auditorium, sir!) ;-)
--
Sam Edge
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: using Windows links
Mellman Thomas wrote in <BE684E2C997AD51199530002A56B20796C3644@MCHH2A1E> on Thu, 2 May 2002 16:53:06 +0200: > There's no h.lnk here. > Is this just a question of having the right frame-of-mind? Yes there is. In the same way that the Windows shell always hides the ".lnk" suffix, cygwin1.dll hides it for Cygwin-generated Windows shorcuts- and only for Cygwin-generated shortcuts. (Cygwin-generated ones have the read-only FAT/NTFS attribute set as a first clue and have a marker in them to tell Cygwin that they're symlinks not just shortcuts.) If you don't like this, then put "nowinsymlinks" in your CYGWIN environment variable and ln -s will create old-style Cygwin symlink files (without any extension) instead of Windows shortcuts. An example; $ echo $CYGWIN binmode ntsec notitle check_case:adjust $ ln -s "../RFC Copies/rfc0768.txt" . $ ls -l rfc0768.txt lrwxrwxrwx1 SamEdge None 130 Apr 29 17:11 rfc0768.txt -> ../RFC copies/rfc0768.txt $ ls -l rfc0768.txt.lnk lrwxrwxrwx1 SamEdge None 130 Apr 29 17:11 rfc0768.txt.lnk -> ../RFC copies/rfc0768.txt Looking using CMD.EXE there is only one file "rfc0768.txt.lnk" and with Explorer you see one file "rfc0768.txt" as a shortcut. (You don't see the extension in Explorer even with the option to see extension enabled because HKEY_CLASSES_ROOT\.lnk has a default value "lnkfile" in the registry and HKEY_CLASSES_ROOT\lnkfile contains an empty string value called "NeverShowExt." Here ends the Windows shell tutorial.) ;-) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Color Output with Printf
Westley Weimer wrote in <[EMAIL PROTECTED]> on Thu, 2 May 2002 14:41:24 -0700 (PDT): > Clearly it is possible to get red text in a dos prompt window: cygwin does > it somehow. My personal theory is that the normal cygwin version is doing > some special setup before main is called that causes stdout to be treated > differently. I assume that a Cygwin application running directly in a console window has its standard I/O passed through a terminal emulator inside cygwin1.dll, yes. This appears to be using the WriteConsoleOutput Win32 API call to write both text and attribute information to the console window. > I would like to get red text in a dos window without with either > gcc -mno-cygwin or cl. Does anyone know how to do this? Does anyone know > why "gcc" and "gcc -mno-cygwin" behave differently in this regard? As described above, there must be a basic terminal emulator in cygwin1.dll that provides the cygwin terminal type. If you don't link with this then your code will end up writing directly to the console window without setting attributes. (The console itself doesn't understand ANSI sequences.) For a non-Cygwin application you need to use the Win32 console output routines. Take a look at WriteConsoleOutput and WriteConsoleOutputAttribute in the Win32 API for setting colours. If you don't have MSDN on CD, you should check out the on-line version, in this case http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/conchar_9ktw.asp -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: How do you pronounce GCC and Cygwin?
Mark Sheppardwrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Fri, 3 May 2002 11:15:05 +0100: > I normally pronounce it with a long "i" sound (s-eye-gwin, as > in cyclops or cycle), although I've heard others pronounce it > with a short "i" sound (as in signal) as Cliff seems to. He > doesn't speak for the entire country as I'm in England too! I think the short-i sound is more appropriate since the "cy" part comes from Cygnus. > I can't see how you could pronounce GCC other than saying the > individual letters so I'm not sure why the original poster > asks about that. You could possibly pronounce it as the contracted expletive "Jeez!" ;-) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Support for Windows 2000 Professional
windman J wrote in <[EMAIL PROTECTED]> on Fri, 3 May 2002 15:30:32 -0700 (PDT): > Does Cygwin runs on Win2k Pro as well? * sigh * ;-) From the /front page/ of http://www.cygwin.com/ - near the top, too! "The Cygwin DLL works with all non-beta versions of Windows since Windows 95, with the exception of Windows CE." From the FAQ http://cygwin.com/faq/ "What versions of Windows are supported? ... Cygwin can be expected to run on all modern 32 bit versions of Windows, except Windows CE. This includes Windows 95/98/ME/NT/2000/XP." There is one caveat. The packages available using http://www.cygwin.com/setup.exe run on the x86/PC processor version of Win32, not on the Alpha or other version. As the introduction to the mailing list says (http://cygwin.com/lists.html) you should really read the documentation and FAQ and search the online mailing list archive before posting questions here. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache PHP segmentation fault
Stipe Tolj wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Thu, 09 May 2002 12:48:12 +0200: > > Well, that didn't help. The postinstall script ran without showing any > > errors but the problem is still ocurring when I try to use PHP. > > I still can't see anything wrong with the set-up. > Ok, have you set the php4 handler for the .php extensions in > /etc/apache/httpd.conf? I've got AddType application/x-httpd-php .php in there but there's no AddHandler line. Should there be? > If yes, what exactly happens and when. Is the assigned httpd child > coredumping when you try to access a .php file? The child process terminates with the error message I've already mentioned. There's a small stackdump generated in the same directory as the offending php script but that's all. The web browser gets some of the output before this happens though. It always gets as far as the title of the "apache" section to the phpinfo() output and no further. It behaves exactly the same every time. I don't have a php.ini file anywhere. From the output of phpinfo() that I do get this should be in /usr/local/lib/php.ini. Ah ha! I've copied the php.ini-recommended file from a download of 4.2.0 for Windows native to /usr/local/lib/php.ini and the problem has gone away. No more segmentation faults. Perhaps the package should include a default php.ini file for idiots like me? Thanks anyway. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache PHP segmentation fault
I wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Thu, 09 May 2002 19:29:59 +0100: > Ah ha! I've copied the php.ini-recommended file from a download of > 4.2.0 for Windows native to /usr/local/lib/php.ini and the problem has > gone away. No more segmentation faults. I spoke too soon. I've made some small changes in php.ini and the fault is back but now gets as far as outputing apache APACHE_INCLUDE before the segmentation fault error occurs and the child aborts. Unfortunately I can't use the simpler part of Sukhwinder Singh's suggestion because the package isn't compiled with debug enabled. Perhaps I need to compile my own versions of Apache and mod_php as he suggests to pin down the location. Ho hum. Thanks anyway. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin/Apache with PHP CGI
Further to my problems with the Apache PHP module package I've given up for the moment. Instead I've downloaded the latest 4.2.0 Win32 native PHP ZIP file and unzipped this into its own directory. I've then made sure php-cli.exe, sapi\php.exe and php4ts.dll are in my Windows PATH and copied php.ini-recommended to C:\WINNT\php.ini to get the command line PHP working. Finally, to use this from Cygwin/Apache I've commented out the PHP LoadModule and AddModule lines and created a cgi-bin shell script to run PHP via an Action line in htppd.conf. httpd.conf: ... #LoadModule php4_module lib/apache/libphp4.dll ... #AddModule mod_php4.c ... AddType application/x-httpd-php .php Action application/x-httpd-php "/cgi-bin/php-cgi" ... /var/www/cgi-bin/php-cgi: (or wherever your cgi-bin actually lives) #!/bin/sh export PATH="/bin:$PATH" win_page=`cygpath -w "$PATH_TRANSLATED"` export PATH_TRANSLATED="$win_page" php 2>&1 The crucial bit is converting PATH_TRANSLATED from Cygwin/Posix format to Windows native for PHP.EXE to read. Your PHP script will have to be written with the Windows native filing system in mind so there are a few other variables that might benefit from translation too if your script uses them. Cygwin is automatically translating PATH but DOCUMENT_ROOT and SCRIPT_FILENAME might be needed too. (Although I can't think why.) (I appreciate that CGI is a sub-optimal way of using PHP in Apache but at least this /is/ working for me and allows me to check my code more easily before uploading to my service provider's Apache/PHP server.) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin/Apache with PHP CGI
Graeme Merrall wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Fri, 10 May 2002 16:09:13 +1000: > Sam, your mail keeps bouncing. It makes it hard to want to help you when > you cannot be emailed. Odd. My From header is spam-trapped with ZZZ because this is a public place but your e-mail client should be using Reply-To in preference to that. Reply-To is set to [EMAIL PROTECTED] so that it goes to the mailing list and not just to me. > I have a patched version of PHP-4.2.0 (actually RC4) for Cygwin you can > use. For the moment I'm happy with the native version. (All I wanted it for is to be able to test PHP code before sending it to my - pretty basic - hosting server.) Thanks anyway. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Too stupid to use MinGW?
Jindrich Kubec wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Fri, 10 May 2002 23:56:21 +0200: > I have C++ app. When I compile with -mcygwin (g++), everything is fine. > But I can't use _tcscpy, _topen and similar TCHAR functions. > When I use -mno-cygwin, I can't use STL, it reports missing headers. When I > comment such part, I'm getting missing import __imp_iob. > Is there any solution for me? Take a look at http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html for import libraries for the STL and instructions for enabling C++ MinGW STL and tchar.h support. One point though. Instead of copying c:\cygwin\usr\include\g++-3 into c:\cygwin\usr\include\mingw as suggested it's easier to open a bash shell and cd /usr/include/mingw ln -s ../g++-3 . instead. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: -mno-cygwin does not work for g++ and g77
Robert Collins wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 12 May 2002 19:56:29 +1000: > You are correct, they don't work right. See the mailing list archives > for detailes. In short, someone needs to contribute a mingw package for > c++ support. There's no package but there are libraries available for C++ in MinGW. http://cygwin.com/ml/cygwin/2002-05/msg00652.html -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
setup.exe problem
I've just updated fro openbox-0.99.1-2.tar.bz2 to openbox-0.99.1-3.tar.bz2 on two machines (NT4SP6a and Win95OSR2) and on both it failed to populate /usr/share/openbox with a "menu" file or /usr/share/openbox/styles with any style files except "twice." When I use tar manually all the files are extracted okay so I suspect the problem is with setup.exe. (I've also been having the same trouble as others with setup.exe 2.218.2.4 and 2.218.2.6 not working for "Install from Local Directory." and am having to use 2.194.2.26.) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup.exe problem
Harold L Hunt wrote in <[EMAIL PROTECTED]> on Tue, 14 May 2002 14:56:09 EDT: > You're complaining about openbox, which is a Cygwin/XFree86 package. > You know better than to send this inquiry to the Cygwin list As I explained, I suspect the problem is with setup.exe since the package archive file appears to be perfectly fine. It extracts correctly using tar but not using setup.exe. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup.exe problem
Harold L Hunt wrote in <[EMAIL PROTECTED]>
on Tue, 14 May 2002 16:12:51 EDT:
> The reason I chided you is that I happen to have inside knowledge that this
> is a change ('problem') with the openbox package, not with setup.exe.
Búgger!
My mistake.
Apologies.
--
Sam Edge
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Changes in latest snapshot
Christopher Faylor wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Sun, 12 May 2002 00:49:43 -0400: > I'm thinking about making binmode the default, too. For what it's worth, I'd be happy with that. Only a few of the POSIX tools I can think of object to CR at the end of a line in text files anyway. Most just treat it as extra whitespace which is usually ignored. (Many Windows tools like CL.EXE and Visual Studio are happy with UNIX line endings too.) I think the overhead of explicit file conversions or textmode mounts for certain sub-directories isn't too much of a burden anymore. Having said that, can I ask for the option to binmode UNC pathnames? They appear to be textmode at the moment when I use I/O redirection in the shell from a grep command, even though I've got binmode in CYGWIN. This makes some things I do with .Xdefaults a bit of a pain. (Xlib does object to the CRs.) Thanks. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Possible error in cygpath
Jorg Schaible wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Wed, 15 May 2002 11:44:51 +0200: > If we have to be Win95-compatible still Please don't consider dropping 95 and NT4 support just yet! There are still plenty of us running these OSes for all sorts of reasons. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xterm title not shown
Alexander Gottwald wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin.xfree on Wed, 15 May 2002 17:37:16 +0200 (CEST): > > The title of xterm defined with option -T or -title does not appear in > > the title bar, instead the current directory is shown there. I do not > > know whether this is a problem of xterm or the window manager, but it > > happens both with twm and mwm. > It seems like bash is setting the title. If you use tcsh, the title > of the xterm is not changed. It seems the bash for linux does not have > this behavior. The default /etc/profile sets up PS1 with the xterm escape sequences to put the username and current directory into the title. Either edit /etc/profile or override it in your ~/.bash_profile or ~/.bash_rc. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin/Apache with PHP CGI
Stipe Tolj wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Fri, 17 May 2002 13:45:47 +0200: > I wouldn't be to hard this way. At least anything else except the > phpinfo() apache section seem to work very stable from my testings. > So in a development or production area output of phpinfo() won't be of > interest. > I'd like you still to consider using it if possible and we'll check to > make it then work even for the apache module infos. I've reverted to using the 4.2.0 module. It's still seg-faulting in phpinfo() but some other simple scripts appear to be working okay. By the way, PHP 4.2.1 is now available. Would it make sense to port this to Cygwin first before attempting a debug? -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ssmtp 2.38.7-4 reads headers from message body.
Corinna Vinschen <[EMAIL PROTECTED]> wrote in
<[EMAIL PROTECTED]>
in gmane.os.cygwin on Fri, 17 Oct 2003 11:33:07 +0200:
> I'm not familar with the mail-related RFCs. Is
> it allowed to send lines with DOS lineendings?
The RFCs for SMTP e-mail (RFC2821 and its predecesors) /require/ CR-LF
("\r\n" i.e. "DOS") line endings. (Probably because debugging using
dumb terminals or printers was easier that way in days of yore.)
Regards,
--
Sam Edge
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: ssmtp 2.38.7-4 reads headers from message body.
Corinna Vinschen <[EMAIL PROTECTED]> wrote in
<[EMAIL PROTECTED]>
in gmane.os.cygwin on Fri, 17 Oct 2003 12:26:54 +0200:
> > > The RFCs for SMTP e-mail (RFC2821 and its predecesors) /require/ CR-LF
> > > ("\r\n" i.e. "DOS") line endings. (Probably because debugging using
> > > dumb terminals or printers was easier that way in days of yore.)
> >
> > Interesting. So a check as in ssmtp:
> > while ((fgets (buffer, sizeof buffer, stdin) != NULL) && (buffer[0] != '\n'))
> > {
> > /* It's a header line */
> > }
> > seems a bit oversimplified, right?
>
> Well, this happens when reading the input file. When writing the output
> stream to the mailhub, it uses \r\n explicitely.
> So ssmtp assumes that the input file is using only \n. Of course, ssmtp
> has never been written with textmode mounts in mind...
Answered your own question. :-D
The translation between the SMTP stream's CRLF and the UNIX (or DOS
text-mode) LF is maybe done elsewhere?
Does ssmtp explicitly set stdin to be text-mode? If it's coming from a
UNIX background maybe not. Might be a simple fix then, to get it to do
so before starting to read?
Regards,
--
Sam Edge
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Is there a 'ping' in Cygwin?
Corinna Vinschen <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Fri, 17 Oct 2003 14:03:42 +0200: > Ping isn't part of inetutils. The right answer is, you have ping if > you're running the Windows subsystem on your Cygwin machine. Hehe. I think that deserves a gold star. :-D I love Fridays. -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is there a 'ping' in cygwin?
Christopher Faylor <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin on Mon, 20 Oct 2003 10:36:48 -0400: > >Without the symlink I have to use 'PING.EXE', with it I can use 'ping'. > >Cygwin has two main benefits for me - it makes windows usable (mainly for > >work) and it helps me migrate to linux at home. Hence I would prefer to be > >as unix/linux like as possible - so I use "check_case:strict". > > Seems like a simpler solution would be to: > mv PING.EXE foo > mv foo ping.exe Or, heaven forbid, just use Windows Explorer to rename (F2) "PING.EXE" to "ping.exe". Regards, -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: error installing sshd on win2k3
> I am installing sshd on win2k3. Windows 2300?! Microsoft must be /really/ confident about this version of the OS. ;-) (Sorry.) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin1.DLL soon to be Windows Vista only
Finally I get to go for my MCSE certificate. I can't thank you enough. (Really, I CAN'T.) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: units-2.11-1
On 20/02/2015 22:12, Yaakov Selkowitz wrote: > The following package has been updated in the Cygwin distribution: > > * units-2.11-1 > Thanks for the update but why the dependencies on Python 3 stuff? Seems to work fine without them. (Apologies if I'm repeating something - it's been a while since I was on here.) -- Sam Edge -- 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: chgrp in Windows
On 25/02/2015 00:08, Warren Young wrote:
>> On Feb 24, 2015, at 4:57 PM, Warren Young wrote:
>>
>>> The result of chown I can see in Windows Explorer as the Owner but where is
>>> the group information?
>> It’s over on the Security tab of the same window you’re looking at: “Group
>> or user names”.
> I just remembered that that tab isn’t always visible. If you’re running a
> “home” version of Windows, there’s a pretty good chance you don’t even see
> this tab.
>
> If that’s your situation, you can un-hide this tab:
>
> http://goo.gl/MDoBo1
> http://goo.gl/C2p2N5
>
> That tab can also be hidden because:
>
> - a group policy setting disabled it
>
> - you’re working on a non-NTFS drive
>
> - you’re working on a shared network drive that doesn’t fully support Windows
> security
>
> etc.
>
I'm pretty sure Cygwin uses the NTFS "primary group" in which to store
the POSIX group ID.
Unfortunately, the owning group ("primary group" in
NTFS/Active-Directory-speak) for a file or folder isn't displayed at all
in the Explorer GUI, only the owner (user in POSIX-speak). To confuse
matters more, in Windows the owning user can actually be a group.
The primary group was only there to support things like the (moribund)
POSIX subsystem in Windows NT-series OSes and the network SFU (services
for UNIX) and is not used by the 'native' Windows subsystem at all,
although it is propagated through the CIFS network filesystem which is
handy for us.
You'll need to add a bolt-on (like SFU I think) if you want to see a tab
on the Explorer security settings showing the primary group. Or just use
Cygwin ls. :-)
--
Sam Edge
--
Sam Edge
--
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: mintty hangs after exit
On 22/08/2015 05:05, John Hein wrote: > Andrey Repin wrote at 02:05 +0300 on Aug 22, 2015: > > Just noticed a weird thing. Wonder if anyone can confirm or deny the issue. > > > > 1. Start mintty as `mintty.exe -` (i.e. login shell) > > 2. Execute a command. S.a. "ssh anywhere" > > 3. Exit all running apps. I.e. ^D out of all shells. > > 4. mintty remains running. > > There's no more child processes of it, nothing. It's just stuck around. > > I see that on occasion, but haven't pinned down reliable conditions > for reproducing the symptom. I'm using tcsh as shell (I'm not > claiming a correlation necessarily). What if you hit enter in the > hung window? That usually kicks things into gear causing the process > / window to go away here. > > (I miss 'wchan' in ps output to give a clue what the process is > doing / waiting on.) > I've had exactly the same problem for some time now. I've only seen it happen after a secure shell client connection has been running with the stalled mintty terminal. To the best of my knowledge, it's not happened in any other circumstances. No keystrokes within the mintty session I've found so far will close the window. Any of the GUI ways of closing the window (single mouse click on the close button at the right end of the title bar, double mouse click on window icon at the left end of the title bar, Alt-F4 etc.) close the window and the mintty process exits cleanly. Not a massive problem but slightly annoying. Cygcheck attached. -- Sam Edge -- Sam Edge Cygwin Configuration Diagnostics Current System Time: Sat Aug 22 05:19:26 2015 Windows 7 Home Premium Ver 6.1 Build 7601 Service Pack 1 Path: C:\cygwin64\home\SamEdge\bin C:\cygwin64\usr\local\bin C:\cygwin64\lib\lapack C:\cygwin64\bin C:\cygwin64\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\ProgramData\Oracle\Java\javapath C:\Program Files\Common Files\Microsoft Shared\Windows Live C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static C:\Program Files (x86)\Windows Live\Shared C:\Program Files (x86)\GNU\GnuPG C:\Program Files (x86)\GNU\GnuPG\pub C:\Program Files (x86)\Skype\Phone C:\Binary Output from C:\cygwin64\bin\id.exe UID: 197609(SamEdge) GID: 197121(None) 197121(None) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users)15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication) 401408(Medium Mandatory Level) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'SamEdge' PWD = '/home/SamEdge' HOME = '/home/SamEdge' HOMEPATH = '\Users\SamEdge' APPDATA = 'C:\Users\SamEdge\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'thor' SHELL = '/bin/bash' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'AMD64 Family 16 Model 4 Stepping 2, AuthenticAMD' HISTSIZE = '1000' PROFILEREAD = 'true' WINDIR = 'C:\Windows' CVSROOT = '/home/SamEdge/docs/Technical/Src/CVSROOT' PUBLIC = 'C:\Users\Public' OLDPWD = '/' ORIGINAL_PATH = '/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files/Common Files/Microsoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Common Files/Microsoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/cygdrive/c/Program Files (x86)/Windows Live/Shared:/cygdrive/c/Program Files (x86)/GNU/GnuPG:/cygdrive/c/Program Files (x86)/GNU/GnuPG/pub:/cygdrive/c/Program Files (x86)/Skype/Phone:/cygdrive/c/Binary:/usr/bin' USERDOMAIN = 'thor' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' HISTFILESIZE = '2' !:: = '::\' LS_COLORS = 'tw=31:ow=31' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'SamEdge' PROCESSOR_LEVEL = '16' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'en_GB.UTF-8' USERPROFILE = 'C:\Users\SamEdge' TZ = 'Europe/London' LOGONSERVER = '\\THOR' CommonProgramW6432 = '
Re: mintty hangs after exit
On 22/08/2015 05:54, Thomas Wolff wrote: > Am 22.08.2015 um 06:31 schrieb Sam Edge: >> On 22/08/2015 05:05, John Hein wrote: >>> Andrey Repin wrote at 02:05 +0300 on Aug 22, 2015: >>> > Just noticed a weird thing. Wonder if anyone can confirm or deny >>> the issue. >>> > >>> > 1. Start mintty as `mintty.exe -` (i.e. login shell) >>> > 2. Execute a command. S.a. "ssh anywhere" >>> > 3. Exit all running apps. I.e. ^D out of all shells. >>> > 4. mintty remains running. >>> > There's no more child processes of it, nothing. It's just stuck >>> around. >>> >>> I see that on occasion, but haven't pinned down reliable conditions >>> for reproducing the symptom. I'm using tcsh as shell (I'm not >>> claiming a correlation necessarily). What if you hit enter in the >>> hung window? That usually kicks things into gear causing the process >>> / window to go away here. >>> >>> (I miss 'wchan' in ps output to give a clue what the process is >>> doing / waiting on.) >>> >> I've had exactly the same problem for some time now. > For weeks? Months? Since which version? > Thomas Months at least. I couldn't tell you at which versions of the various players (cygwin, mintty, ssh ...) at which it started, sorry. -- Sam Edge -- 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: Updated [test]: coreutils-8.24-2
On 27/08/2015 00:28, Eric Blake wrote:
> On 08/26/2015 04:50 PM, Fergus wrote:
>>> .. No, you're the first to report it (so 8.24-2 has the same issue), but
>>> now that I know about it, it will get fixed soon.
> Spot the bugs:
>
> int
> cygwin_spelling (char const *path)
> {
> ...
> int len;
> ...
> if (! path || ! *path || len > PATH_MAX)
> /* PATH will cause EINVAL or ENAMETOOLONG, treat it as non-existing. */
> return -1;
> len = strlen (path);
>
>
> D'oh. But this same flub of mine was also present in at least 8.23-4; so
> it was the upstream churn in src/cp.c that caused the stack to be
> different to the point that it now matters.
>
> [For those keeping score, I should use size_t and not int to store
> strlen() values, since it matters on 64-bit when encountering the
> unlikely >2G string; and it helps to never branch on uninitialized memory]
>
One might add, "Always, always initialize automatic variables. This
ensures deterministic behaviour. The compiler will optimise out the
redundant ones."
Rapid diagnosis once reported so I'll let you off this time, Eric. ;-)
--
Sam Edge
--
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: Updated [test]: coreutils-8.24-2
On 27/08/2015 21:33, Helmut Karlowski wrote: > Did you mean: "The compiler-warning would inform you that the value is > not set in a code-path"? I'd agree if I was always in the position of starting projects from scratch. All compiler warnings should be errors and disabling a compiler warning has to have a valid justification during review, yes. But try it with an existing code base. That's when you need deterministic behaviour from your modifications with minimal disturbance to anything else. > That's why I usually try to avoid initializing auto-variables (and > maybe save some bytes). If you can afford the tech debt recovery time to change your compiler warnings to errors or sift through the build output - and prove to your QA/RA that you don't have to re-certify the product. But you're unlikely to save any bytes using a modern compiler. Anyway, we're off-topic so adieu. -- Sam Edge -- 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: Question about flock - potential memory corruption?
On 07/09/2015 19:45, Qian Hong wrote: > Hi, > > Attach is the simple test case I use to reproduce the valgrind warning > and random failures. > > Compile the test case in Cygwin with below command line: > $ gcc -g -O0 flock.c -o flock.exe > > Thanks! > Hi, Erm ... slight technical hitch? Your example flock.c doesn't call fork(), nor does it use your two macros MAX_ITER & CHILDREN. -- Sam Edge -- 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: SegFault running "ls -l" after Microsoft Patch Day
On 18/12/2015 13:06, Dr Rainer Woitok wrote: > and (of all things!) contain blanks, * rant mode on * What's wrong with blanks? The OS calls don't give a monkey's chuff so long as they're given null-terminated C-strings. Tools like find, xargs etc. have options to cope. The biggest problem is that there are a lot of sloppily written shell scripts out there that don't properly quote substitutions or that use $* instead of "$@" or that use command substitution where they should be using pipes and "xargs" and "read". That's the fault of the scripts, not the OS/emulation layer. * rant mode off * Happy Holidays everyone. -- 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: SegFault running "ls -l" after Microsoft Patch Day
On 20/12/2015 13:31, Houder wrote: > > Yes Corinna, I "heard" you the first time ... > > ... as I said, it must be my __old__ age. Let us stop at that. > > Regards, > Henri > > Should I be asking for subscriptions to the System V wrinklies' club at this point? :-; (Wasn't expecting my little polemic would generate such interest, especially from such exalted company. I'll try to shut up for the rest of the year now anyway.) :-) Best wishes, Sam -- 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: svn segfault when using svn+ssh schema
On 09/01/2017 19:07, Sam Edge wrote:
> On 09/01/2017 02:04, Eliot Moss wrote:
>> On 1/8/2017 3:45 PM, David Rothenberger wrote:
>>> On 1/8/2017 6:12 AM, Sam Edge wrote:
>>>> I've seen a number of 'svn segfault' threads on the mailing list
>>>> archive
>>>> but none of them seem to cover this specific failure mode.
>>>> (Apologies if
>>>> one of them does!)
>>>>
>>>> I'm getting segfaults from svn but only when using ssh as the schema.
>>>> The following three commands are all accessing the same server, the
>>>> name
>>>> of which has been changed to protect the guilty.
>>>>
>>>>
>>>> SamEdge@thor ~
>>>> $ ssh cmserver.XX.com
>>>> ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
>>>> commit-revprops depth log-revprops atomic-revprops partial-replay
>>>> inherited-props ephemeral-txnprops file-revs-reverse ) ) )
>>>> SamEdge@thor ~
>>>> $ svn ls svn+ssh://cmserver.XX.com/edl/
>>>> Segmentation fault (core dumped)
>> Assuming this is repeatable behavior, perhaps getting a trace using
>> strace would reveal some more useful information.
>>
>> Regards - Eliot Moss
>>
> Good idea.
>
> Strangely, on another Windows 7 64-bit machine svn+ssh to the same
> server is working fine for me. The most significant differences are that
> the 'working' machine is running Windows 7 Pro on an Intel CPU with
> Sophos AV and domain accounts whereas the 'failing' machine is Windows 7
> Home Premium on an AMD with MS Security Essentials and local accounts.
> These differences may or may not be relevant of course.
>
> Anyway, attached are the two strace outputs. Diffing them suggests that
> it's segfaulting in the fork() "system" call.
>
> I don't have time in the week to run it in a debug session but I'll try
> to do so at the weekend given the advice I've been given here. I will
> also do a rebaseall after I've tracked down the
>
> Thanks for the feedback folks. Much appreciated.
>
> BR
Hi again.
I've downloaded the debug symbols for subversion & the Cygwin dll and
run the command in gdb. Output attached. Not really giving me any clues
so far.
I've also run 'rebaseall' on the off chance that it would help - it didn't!
Still open to suggestions if anyone has any "light bulb" notions. :-)
--
Sam Edge
SamEdge@thor ~
$ gdb svn
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from svn...Reading symbols from
/usr/lib/debug//usr/bin/svn.exe.dbg...done.
done.
(gdb) set cygwin-exceptions on
(gdb) run ls svn+ssh://cmserver.XX.com/edl/
Starting program: /usr/bin/svn ls svn+ssh://cmserver.XX.com/edl/
[New Thread 2096.0xf4c]
[New Thread 2096.0x157c]
[New Thread 2096.0x1264]
[New Thread 2096.0x15d8]
Program received signal SIGSEGV, Segmentation fault.
0x0003e9f63780 in ?? ()
(gdb) bt
#0 0x0003e9f63780 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info threads
Id Target Id Frame
4Thread 2096.0x15d8 0x76cfd63a in
ntdll!ZwWaitForWorkViaWorkerFactory () from
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
3Thread 2096.0x1264 0x76cfc2ea in ntdll!ZwWaitForMultipleObjects
() from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
2Thread 2096.0x157c 0x76cfbd9a in ntdll!ZwReadFile ()
from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
* 1Thread 2096.0xf4c 0x0003e9f63780 in ?? ()
(gdb) list
3098 err, _("When using svn+ssh:// URLs, keep in mind that
the "
3099 "--username and --password options are ignored
"
3100 "because authentication is performed by SSH,
not "
3101 "Subversion"));
3102}
3103
3104 return err;
3105}
3106
3107 return SVN_NO_ERROR;
(gdb)
--
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: svn segfault when using svn+ssh schema
On 16/01/2017 20:26, Jon Turney wrote: > On 16/01/2017 20:07, Sam Edge wrote: >> On 09/01/2017 19:07, Sam Edge wrote: >>> On 09/01/2017 02:04, Eliot Moss wrote: >>>> On 1/8/2017 3:45 PM, David Rothenberger wrote: >>>>> On 1/8/2017 6:12 AM, Sam Edge wrote: >>>>>> I've seen a number of 'svn segfault' threads on the mailing list >>>>>> archive >>>>>> but none of them seem to cover this specific failure mode. >>>>>> (Apologies if >>>>>> one of them does!) >>>>>> >>>>>> I'm getting segfaults from svn but only when using ssh as the >>>>>> schema. >>>>>> The following three commands are all accessing the same server, the >>>>>> name >>>>>> of which has been changed to protect the guilty. >>>>>> >>>>>> >>>>>> SamEdge@thor ~ >>>>>> $ ssh cmserver.XX.com >>>>>> ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries >>>>>> commit-revprops depth log-revprops atomic-revprops partial-replay >>>>>> inherited-props ephemeral-txnprops file-revs-reverse ) ) ) >>>>>> SamEdge@thor ~ >>>>>> $ svn ls svn+ssh://cmserver.XX.com/edl/ >>>>>> Segmentation fault (core dumped) >>>> Assuming this is repeatable behavior, perhaps getting a trace using >>>> strace would reveal some more useful information. >>>> >>>> Regards - Eliot Moss >>>> >>> Good idea. >>> >>> Strangely, on another Windows 7 64-bit machine svn+ssh to the same >>> server is working fine for me. The most significant differences are >>> that >>> the 'working' machine is running Windows 7 Pro on an Intel CPU with >>> Sophos AV and domain accounts whereas the 'failing' machine is >>> Windows 7 >>> Home Premium on an AMD with MS Security Essentials and local accounts. >>> These differences may or may not be relevant of course. >>> >>> Anyway, attached are the two strace outputs. Diffing them suggests that >>> it's segfaulting in the fork() "system" call. > > Not quite, this strace has... > >> --- Process 5436 loaded C:\cygwin64\lib\sasl2_3\cygcrammd5-3.dll at >> 0003EA09 >> --- Process 5436, exception c005 at 0003EA023780 >> --- Process 5436 unloaded DLL at 0003EA09 >> 333 52465 [main] svn 5436 seterrno_from_win_error: >> /home/corinna/src/cygwin/cygwin-2.6.1/cygwin-2.6.1-1.x86_64/src/newlib-cygwin/winsup/cygwin/dlfcn.cc:304 >> windows error 998 >>24 52489 [main] svn 5436 geterrno_from_win_error: windows error >> 998 == errno 14 >>20 52509 [main] svn 5436 dlopen: ret 0x0 > > and then a bit later > >>21 91851 [main] svn 5436 fork: entering >> 168 92019 [main] svn 5436 sig_send: sendsig 0x80, pid 5436, >> signal -72, its_me 1 >>19 92038 [main] svn 5436 sig_send: wakeup 0x28C >>24 92062 [main] svn 5436 sig_send: Waiting for pack.wakeup 0x28C >>36 92098 [sig] svn 5436 wait_sig: signalling pack.wakeup 0x28C >>27 92125 [main] svn 5436 sig_send: returning 0x0 from sending >> signal -72 >> --- Process 5436, exception c005 at 000180053D3F > > So it looks like perhaps cygcrammd5 is faulting during it's DllMain, > and perhaps this leaves things in a state that dll_list::topsort can't > handle... > >>> I don't have time in the week to run it in a debug session but I'll try >>> to do so at the weekend given the advice I've been given here. I will >>> also do a rebaseall after I've tracked down the >>> >>> Thanks for the feedback folks. Much appreciated. >>> >>> BR >> >> Hi again. >> >> I've downloaded the debug symbols for subversion & the Cygwin dll and >> run the command in gdb. Output attached. Not really giving me any clues >> so far. > > You also need the symbols for the DLL loaded at the faulting address. > > From previous information I'd guess that is cyrus-sasl-debuginfo. > > (you can check this using gdb's 'info shared' command) > >> I've also run 'rebaseall' on the off chance that it would help - it >> didn't! >> >> Still open to suggestions if anyone has any "light bulb" notions. :-) > Hi Jon. Thanks for the swift reply. I've installed the debu
Re: cygpath
On 10/02/2017 23:17, Eliot Moss wrote: > On 2/10/2017 3:03 PM, Gluszczak, Glenn wrote: >> * is a legal character for ls but perhaps not cygpath? I don't know. >> No files or directories are using * in the name. >> >> Not sure about incorrect terminal settings as I never touched any. >> It shows up in mintty and ssh equally. The characters that appear vary. >> >> Some non-existent paths do *not* produce the gibberish. >> >> %%%cygpath -w /aaa/bbb/* >> C:\cygwin\aaa\bbb\ > > Yes, but I found something interesting when I did this: > > echo "$(cygpath -w /usr/non-existent/*)" > mytemp > > od -c mytemp > > revealed that there is a three-byte sequence after the > output of > > C:\cygwin\usr\non-existent\ > > and before the newline added by echo. I guess it's > some representation of * that does not show up on the > terminal, but it did strike me as a little strange ... > > Regards - EM > > -- > 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 > > Sorry, did anyone actually read Andrey's post? (Hint: Read https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars again.) The three byte sequence is the UTF-8 representation of U+F02A i.e. ASCII for '*' but in the private use area of Unicode. This is how the Cygwin DLL stores ASCII characters in pathnames that are forbidden in Windows but that are valid in POSIX. The directory entry write functions convert them to private area and the read functions convert them back to Unicode. The cygpath utility therefore does exactly the same on the assumption that the result is going to be passed to Windows programs that are going to manipulate the directory entry in some way - open the file for example. That they display incorrectly is an inevitable side effect of this work-around. Generally, all you need to do is accept the Copenhagen interpretation in your scripts and just calculate. ;-) The only thing you need to be careful of is that if you really mean to pass the glob to your Windows app, you leave it out of the string passed to cygpath e.g. cygstart some-exe "$(cygpath -w "some-posix-path/")"\* instead of cygstart some-exe "$(cygpath -w "some-posix-path/*")" -- Sam Edge -- 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: cygpath
On 11/02/2017 00:05, Eliot Moss wrote: > On 2/10/2017 6:50 PM, Sam Edge wrote: > >> Sorry, did anyone actually read Andrey's post? > > Yes, but I was going through the emails in order and responded > to the earlier one before I got to the later one. Sorry to have > added noise to the list ... > No prob. Perhaps a little over-exasperated here. sorry. Not an excuse but it's been a long week! Off to watch Tucker and Dale ... :-) -- Sam Edge -- 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: sshd permits logon using disabled user?
On 27/01/2019 22:10, Corinna Vinschen wrote: > On Jan 27 17:49, Sam Edge (Cygwin) wrote: >> On 25/01/2019 18:03, Bill Stewart wrote: >>> On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier >>> wrote: >>> >>>> There are different paths to access and to completely disable the account >>>> you need to close all of them. There are many reasons to disable some >>>> paths without disabling all paths and converting the switch that can >>>> disable one path to a switch that will disable all paths will break >>>> some setups and be less flexible. (As Stefan Baur is pointing out >>>> effectively.) >>>> >>>> To disable ssh logins really, instead of changing the way Cygwin works >>>> for everyone, you could do what UNIX/Linux admins do, something like >>>> moving the user .ssh folder to .ssh.disabled. >>> This is a very problematic view from a Windows system management >>> perspective. >>> >>> I respectfully (and strongly) disagree, for at least the following reasons: >>> >>> * Cygwin runs on Windows, and as such should respect Windows security. >>> It is very unexpected, from a Windows administration perspective, to >>> have a disabled account and still be able to log onto it. >>> >>> * Proper system management/security mitigation is made quite complex >>> with this requirement. Imagine even a small Windows domain: I have to >>> scan 2 machines in my domain to find out if they're running ssh, >>> troll through the disks to find ssh config files, find out the key >>> file names, rename them, etc. This is quite a bit harder to do than >>> just disabling accounts, which in many organizations is handled by an >>> automated process. >>> >>> Regards, >>> >>> Bill >> >> I totally agree that Cygwin should respect the Windows disabled & >> locked-out semantics and disallow any form of login where either is set. >> Trying to shoe-horn the disabled password but enabled pubkey function >> into one or the other just doesn't feel right. Setting a hugely long >> random password (maybe via a script that never reveals said password) is >> a much better solution to achieve a similar effect without breaking >> Windows security auditing. >> >> On the other hand, I am baffled as to why Windows itself allows a token >> to be created for an account that is disabled or locked out. If Cygwin >> can do it, other programs could too so you're still vulnerable. > No, Windows doesn't allow that unless the process has very specific > privileges. But keep in mind that a token is required to do stuff on > behalf of a user. So even if the user is disabled from interactive > logon, a service process might have a valid reason to create a token > for that user to perform a non-interactive purpose. > > In terms of these special privileges, right now we require these > privileges for an account which switches the user (e.g., via sshd > installed as a service), as outlined in > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1 > > However, this should change with the upcoming 3.0 release of Cygwin > which replaces the "create token" method with another method called > "S4U". This method creates perfectly valid tokens with only documented > functions without requiring any super-special permissions. > > I'm pretty excited about this change because it drops the requirement > to create a special CYgwin service account. sshd and other services > can finally run under the normal LocalSystem account again. > > This patch is available in the most recent developer snapshot from > https://cygwin.com/snapshots/ btw. > > > Corinna > Hi Corinna. Thanks for the explanation. And the heads-up on the change. Having a rummage through docs out of curiosity. (Tangential to my day job.) I think I grok Win32 and Linux FS ACLs but my expertise on OS process security models peaked somewhere around System V. :-S Anyway, the fact that activity can still occur in the name of disabled/locked-out accounts is, perhaps, something that people in Bill's position should consider, given his concerns. But that's rather OT. As ever, kudos to yourself and the rest of the contributors to Cygwin. Still my go-to tool wherever I land. -- 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: cygwin can not be compiled with gcc 8.3.0
On 05/07/2019 18:03, Biswapriyo Nath wrote: > > If it is deprecated then why the FAQ is not fixed yet? > As is normal, I'll think you'll find https://cygwin.com/acronyms/#PTC. -- 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: cygwin can not be compiled with gcc 8.3.0
On 05/07/2019 21:46, Biswapriyo Nath wrote: > Now I'm sure that the issue in cygwin source code. I've installed all the > components. Also find same issue[1] provided a year ago. Cygwin needs some > papering[2] for gcc 8.3.0. > Hi again. I don't want to sound mean (https://cygwin.com/acronyms/#WJM) but ... Since you're the one who wants to build Cygwin using gcc 8.3.0, then why don't you create appropriate patches and submit them for consideration? https://cygwin.com/acronyms/#PTC and all that. Regards. -- 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: rename a user using setfacl -- possible? how?
On 06/07/2019 10:39, L A Walsh wrote: > My machine's GUID changed. This file has entry for userX > on the old machine-GUID. UserX also exists on the new machine GUID. > > So I renamed the old entry to UserXold so I could find all the places > where the old GUID is referenced then change it to the machine's new guid. > > I'm not having cygwin create new groups or whatever, but trying to replace > references to this Userid in the machine's old GUID and replace them with > reference to the Uid with the machine's new GUID. > > if it was the main group, I'd just use find to locate instances of old > and do chgrp to change ownership to new. However, this is a group entry > in an acl list -- so I need to change the name of 1 entry in the acl list. This sounds like a Windows maintenance issue. While you can use Cygwin tools to manipulate the NTFS ACLs I'd be inclined to look at native tools, probably using a Powershell script if you need to automate it. If you use setfacl on paths outside your 'Cygwin domain' it's going to mess up the more normal Windows/NTFS ACL usage especially the inheritance and ordering. -- Sam Edge -- 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: Dependency issues in setup.ini.
Hi Andrey. Nice to be back in a thread with such esteemed folk. ;-) On 30/09/2017 10:00, Andrey Repin wrote: > Greetings, Sam Edge (Cygwin)! > >> I've been developing a Python package that can interrogate and >> manipulate local package caches (the directories where setupXXX.exe >> keeps its downloads) and installation databases (from Cygwin >> /etc/setup/installed.db files) with a mind to pruning, merging and >> reporting in the spiript of Michael A. Chase's 'clean_setup' utility but >> as a scriptable tool set rather than a stand-alone utility. > I'm eager to see the fruits of your labor. Don't hold your breath! :-) I'm doing it partly to teach myself the subtleties of Python classes and I've not yet got to the process of turning it into an installable import module. Also, its re-based parser is still a bit naive. It works okay with the current setup.ini but it has vulnerabilities I'd like to eliminate.(Hopefully I'll have something I won't be embarrassed to share before Yuletide.) >> It's not production ready yet but it's already flagged up some issues. >> For example we have lots of dependency loops in the 'requires' fields in >> setup.ini - even to the point that some packages depend upon themselves! > Dependency upon itself is curious, but other than that, this is a normal > situation for a package manager. Some packages are split for easier > maintenance of each, but are interlocked in their typical usage pattern. Ah, okay. Fair enough. It can be difficult to keep things layered purely up & down I know. Although often it can be resolved by introducing a third module that acts as the muxer between the other two to avoid cross API dependencies. But that's a discussion for another mailing list. But I'm also seeing loops deeper that X->Y->X. More like X->Y->Z->W->X. (The self-dependency is cygwin-debuginfo by the way.) >> And also we have some dependency omissions. For example, mintty doesn't >> depend upon anything - it has no requires field. Surely, every binary >> package should depend at least upon 'cygwin'? > While this is "not good", this is also not particularly bad for packages in > base - this group is always installed. Indeed. However, while off label usage of Cygwin is anathema to me but sometimes I wish 'base' wasn't quite so big and have to pare things down a little once installed, e.g. as part of a makefile- and/or Eclipse-based build tree in source code control.(Which was also one of my motivations for the Python stuff.) >> Is this a known issue or should I report in more detail? > Nonetheless, such issues are best kept highlighted, unless it is clearly > seen/documented as intended. > Will try to collate a list as soon as I have a free (as in not too bushed) weekday evening. -- 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: Dependency issues in setup.ini.
On 30/09/2017 12:23, Andrey Repin wrote: > >> Indeed. However, while off label usage of Cygwin is anathema to me but >> sometimes I wish 'base' wasn't quite so big and have to pare things down >> a little once installed, e.g. as part of a makefile- and/or >> Eclipse-based build tree in source code control.(Which was also one of >> my motivations for the Python stuff.) > Rational suggestions are always welcome, I suppose. > While my own usage of Cygwin is prone to spread thin across all aspects of my > daily work, I can see situations, where a much smaller subset of packages > (let's name it "core" or something) would be beneficial. I.e. when packaging > Cygwin as part of your own application. > > Again, agree. A 'core' package that has enough to get a shell up (preferably dash not bash) would be very useful. I don't believe in packaging Cygwin with an application - I'd rather say "as a prerequisite, you need to have a Cygwin installation newer than v.X" - but for build systems where you're trying (somewhat in vain sometimes I know) to attempt deterministic behaviour it would be nice to have a smaller subset upon which you could add just what's needed, usually make, grep, sed, cp, mv & rm & maybe a scripter such as awk, perl, tcl (or python!) depending upon. Anyway, it's the weekend so I'm off. Enjoy, -- Sam -- 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: substitute for xclip?
Hi there. In the absence of a Cygwin-native utility, how about? x="$(powershell -command Get-Clipboard)" You can pipe to the Windows 'clip' utility to go the other way or use 'powershell -command Set-Clipboard'. But I agree, a Cygwin utility would be nice, unless there already is one? -- Sam Edge On 19/10/2022 07:58, Ulli Horlacher wrote: With Linux I am using xclip to read the X11 clipboard. Is there a cygwin equivalent to read the Windows clipboard? My use case is: The user copies file names to the clipboard and then starts a program which processes these files. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: substitute for xclip?
H again. Or you can use:- #!/bin/bash shopt -s lastpipe powershell -command Get-Clipboard | mapfile array_variable for multiline. -- Sam Edge On 19/10/2022 08:44, Sam Edge wrote: Hi there. In the absence of a Cygwin-native utility, how about? x="$(powershell -command Get-Clipboard)" You can pipe to the Windows 'clip' utility to go the other way or use 'powershell -command Set-Clipboard'. But I agree, a Cygwin utility would be nice, unless there already is one? -- Sam Edge On 19/10/2022 07:58, Ulli Horlacher wrote: With Linux I am using xclip to read the X11 clipboard. Is there a cygwin equivalent to read the Windows clipboard? My use case is: The user copies file names to the clipboard and then starts a program which processes these files. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: substitute for xclip?
On 19/10/2022 10:01, Backwoods BC wrote: > On Tue, Oct 18, 2022 at 11:59 PM Ulli Horlacher > wrote: >> >> With Linux I am using xclip to read the X11 clipboard. >> Is there a cygwin equivalent to read the Windows clipboard? > > There are 2 ways to access the clipboard: > 1. The commands 'getclip' and 'putclip' > 2. Redirection to/from /dev/clipboard > Eek. I knew that. I use them all the time. Apologies for the bad steer ... and for top-posting! -- Sam Edge OpenPGP_signature Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: substitute for xclip?
On 19/10/2022 23:52, Oliver Schoede wrote: Hi! On Wed, 19 Oct 2022 14:58:42 +0200 Ulli Horlacher wrote: https://fex.rus.uni-stuttgart.de/fop/jFZ6T7wI/X-20221019141237.png I have selected [copy] in the file browser, but /dev/clipboard is empty. Also getclip gives me no output. It looks to me like you copied the file, not the file name? To clarify the above, Windows has a non-text clipboard data type when 'copying' a file in the File Explorer which encodes additional information other than its path. This is to allow the equivalent 'paste' function in Explorer and other file-accepting GUI applications to work more intelligently. Unfortunately, Cygwin's /dev/clipboard and get/putclip only process text formats. I imagine your X file manager is simply copying a textual representation of the file path to the clipboard when you choose 'copy' which of course can be extracted by scripts etc. It appears that Windows Explorer doesn't also place a textual representation onto the clipboard (the Windows clipboard allows multiple representations to exist simultaneously) which is what would be required for Cygwin to use it at present. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: A notion about saving and restoring Windows file security info
On 05/01/2022 17:41, Eliot Moss wrote: Therefore, my thought is to make the presentation of these attributes by attr_list (is that the canonical call?) and probably also the special interpretation of them for get/set, controllable in some way. The means of control that occurs to me is an environment variable, or a flag within the CYGWIN env var. Other folks more deeply involved in Cygwin library code, etc., may have a more informed notion of the best way to control this, but it strikes me as one of those things that you would have to ask for. In principle, each of Attrs, SDs, and ADS_ could be separately controlled, if we think that is important (might be). Hi Eliot. I can see the appeal of mapping hidden/system/readonly to suitably namespaced xattrs and exposing ADSes. However I would caution about having too many selectable options as the behaviour for every combination in the running system would have to be considered against filesystems that have been manipulated with every other combination. As the recent update to setup.exe has shown, even the different types of symlink handling can cause unforeseen problems and that's a single option with only a few possible values that only affect how they're written and not how they're read. Just a thought. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Perl has slowed in recent months
On 24/05/2022 09:25, Csaba Raduly wrote: > On Mon, 23 May 2022 at 20:47, Lee wrote: >> >> On 5/22/22, David Christensen wrote: >>> On 5/21/22 10:55, Hans-Bernhard Bröker wrote: >>>> Am 18.05.2022 um 03:53 schrieb David Christensen: >>>> >>>> > I am working on a Perl module that runs on various Unix-like platforms. >>>> > When I 'make test' on similar computers: >>>> > >>>> > FreeBSD 12.3-RELEASE 28 wallclock secs >>>> > Debian GNU/Linux 11.3 31 wallclock secs >>>> > macOS 11.6.2 36 wallclock secs >>>> > Windows 7 / Cygwin 3.3.5-1 509 wallclock secs >>>> >>>> Given the complete lack of information about what that Perl module of >>>> yours might be doing, that's hard to have a meaningful discussion about. >>> >>> >>> Thank you for the response. I was hoping there was a known issue. >>> Apparently, not. >> >> What I consider a well known issue is that process start up time is >> _very_ slow. If your 'make test' starts lots of processes that could >> be a problem. >> > > While Cygwin''s fork emulation is indeed slow (I once measured 1000:1 > between Cygwin and Linux * ), > "make test" likely started roughly the same number of processes "then" > as it does "now". > In which case the increase in the run time could be attributed to Cygwin. Indeed. But perhaps what the Cygwin core and/or Cygwin Perl maintainers need is a simple test case Perl script that can be shown to be much slower on the current releases than it was on a named earlier pair of releases. And maybe some testing by the original poster to see if it is the Cygwin or Perl release change that causes the issue. Anecdotal observations do not an issue report make. ;-) -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Perl has slowed in recent months
On 24/05/2022 16:03, David Christensen wrote: On 5/24/22 01:47, Sam Edge wrote: On 24/05/2022 09:25, Csaba Raduly wrote: > On Mon, 23 May 2022 at 20:47, Lee wrote: >> >> On 5/22/22, David Christensen wrote: >>> On 5/21/22 10:55, Hans-Bernhard Bröker wrote: >>>> Am 18.05.2022 um 03:53 schrieb David Christensen: >>>> >>>> > I am working on a Perl module that runs on various Unix-like platforms. >>>> > When I 'make test' on similar computers: >>>> > >>>> > FreeBSD 12.3-RELEASE 28 wallclock secs >>>> > Debian GNU/Linux 11.3 31 wallclock secs >>>> > macOS 11.6.2 36 wallclock secs >>>> > Windows 7 / Cygwin 3.3.5-1 509 wallclock secs >>>> >>>> Given the complete lack of information about what that Perl module of >>>> yours might be doing, that's hard to have a meaningful discussion about. >>> >>> >>> Thank you for the response. I was hoping there was a known issue. >>> Apparently, not. >> >> What I consider a well known issue is that process start up time is >> _very_ slow. If your 'make test' starts lots of processes that could >> be a problem. >> > > While Cygwin''s fork emulation is indeed slow (I once measured 1000:1 > between Cygwin and Linux * ), > "make test" likely started roughly the same number of processes "then" > as it does "now". > In which case the increase in the run time could be attributed to Cygwin. Indeed. But perhaps what the Cygwin core and/or Cygwin Perl maintainers need is a simple test case Perl script that can be shown to be much slower on the current releases than it was on a named earlier pair of releases. And maybe some testing by the original poster to see if it is the Cygwin or Perl release change that causes the issue. Anecdotal observations do not an issue report make. ;-) So, we are discussing running a Perl benchmark for various combinations of Cygwin version and/or Cygwin Perl version. That is an O(n) and/or O(n**2) problem. If multiple benchmarks are considered, increase the O() exponent by one. If multiple versions of Windows are considered, increase the O() exponent by one. If multiple computers are considered, increase the O() exponent by one. Does the Cygwin project do any of the above? If so, how? Where are the test plans and assets? Where is the raw data? Where are the reports? If end users are expected to do the above, please advise: 1. How to install multiple versions of Cygwin on Windows 7 Professional 64-bit Service Pack 1 on an x86_64 computer such that each instance of Cygwin does not interact with any other instance of Cygwin. 2. How to install multiple versions of Cygwin Perl on each of many Cygwin installations on Windows 7 Professional 64-bit Service Pack 1 on an x86_64 computer such that each instance of Cygwin Perl does not interact with any other instance of Cygwin Perl or Cygwin. 3. What is a suitable Perl benchmark? David The Cygwin core & Perl maintainers do not get paid for their work. If you believe you have spotted a regression, it's up to you to isolate at what revision of Perl or of Cygwin core it started to happen. You can get older revisions of Cygwin & Perl from the Cygwin Time Machine (GFGI). You can have as many parallel installations of Cygwin and its packages as you like simply by specifying different install paths when running the setup program (RTFM). Like most FOSS, Cygwin & its packages are provided with no warranty. If they are so vital to your business, you need to be doing regression testing yourself before upgrading production systems and maintaining your own Cygwin repo so you have a copy of the production releases. This is all SOP for using FOSS in a business context, unless you're willing to pay someone else to do it for you, which is how Red Hat et al make their money. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Unable to execute Cygwin application within UDF format
On 27/05/2022 10:18, Takashi Yano wrote: On Fri, 27 May 2022 16:47:09 +0800 Sam Lin wrote: I have also successfully executed that is to move cygwin1.dll to the root directory to execute. Will cygwin1.dll be supported to execute in UDF format in the future? As I wrote earlier, it doesn't matter that the file system is UDF. cygwin1.dll 3.2.0 and later seems to cause problems if it is placed in the root directory. Even with UDF format, the problem does not occur if hello.exe and cygwin1.dll are placed in any directory other than root directory. Perhaps the Cygwin DLL is trying to identify the Cygwin root directory as one higher than its own location so that it can locate /etc/fstab etc. If it's in the root of a drive maybe it's getting confused. Create an x:\bin\ directory (where x is the drive letter of the UDF device) into which to place cygwin1.dll and the executable. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Wish list: Cygwin `mv` to move OneDrive files without downloading them
On 14/06/2022 12:25, Adam Dinwoodie wrote: > Microsoft OneDrive has a "Files On-Demand" function, where it will > synchronise file metadata to a local system, but won't actually download > the file content until an application attempts to read the content. > When moving a file within Cygwin using `mv`, the file always gets > downloaded, which seems like it shouldn't be necessary. Is there any > way to have `mv` (and presumably the underlying rename call) work > without downloading the file content in this circumstance? It'd > definitely make some of my life easier, but I'm not sure if it's a > trivial issue, one that would require years of work, or somwhere in > between... > > As best I can tell, `mv` doesn't need to know the content of the file, > at least as long as it's not moving the file outside of OneDrive; it > feels very similar to me to moving a file within a partition on *nix: > generally it's just a case of updating the directory records, with no > need to look at the file content. > > This does work as desired from within PowerShell: PowerShell's > `Move-Item` won't download a file that's not currently stored on the > local system. So it's presumably possible to achieve this, although I > don't know if it'd rely on non-public Microsoft APIs, and/or lots more > complexity in the Cygwin code. > > Simple demonstration below, showing the different behaviours of > PowerShell versus Cygwin. I've not included a cygcheck.out, as I'm > pretty sure this is much closer to a feature request than a problem > report, but let me know if I've got that wrong. Greetings Adam. I wasn't even aware you could do that with OneDrive - there's still no Explorer way of doing it in Windows 10 21H2 as far as I can see. Thanks for the info. :-) I imagine Cygwin doesn't know about the extended attributes being used within the local copy of your OneDrive directory so it is doing the move using the underlying POSIX 'rename within mount' API which hopefully uses the Win32 'rename' but not in a way that carries the new 'O' attribute. Presumably PowerShell's Move-Item does use the right flags to the Win32 API call. One of the problems the Cygwin maintainers have is that Microsoft introduces 'enhancements' to NTFS & the Win32 API arbitrarily in Windows updates without announcing them so it's a game of whack'a'mole. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: sshd permits logon using disabled user?
On 25/01/2019 18:03, Bill Stewart wrote: > On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier > wrote: > >> There are different paths to access and to completely disable the account >> you need to close all of them. There are many reasons to disable some >> paths without disabling all paths and converting the switch that can >> disable one path to a switch that will disable all paths will break >> some setups and be less flexible. (As Stefan Baur is pointing out >> effectively.) >> >> To disable ssh logins really, instead of changing the way Cygwin works >> for everyone, you could do what UNIX/Linux admins do, something like >> moving the user .ssh folder to .ssh.disabled. > This is a very problematic view from a Windows system management perspective. > > I respectfully (and strongly) disagree, for at least the following reasons: > > * Cygwin runs on Windows, and as such should respect Windows security. > It is very unexpected, from a Windows administration perspective, to > have a disabled account and still be able to log onto it. > > * Proper system management/security mitigation is made quite complex > with this requirement. Imagine even a small Windows domain: I have to > scan 2 machines in my domain to find out if they're running ssh, > troll through the disks to find ssh config files, find out the key > file names, rename them, etc. This is quite a bit harder to do than > just disabling accounts, which in many organizations is handled by an > automated process. > > Regards, > > Bill I totally agree that Cygwin should respect the Windows disabled & locked-out semantics and disallow any form of login where either is set. Trying to shoe-horn the disabled password but enabled pubkey function into one or the other just doesn't feel right. Setting a hugely long random password (maybe via a script that never reveals said password) is a much better solution to achieve a similar effect without breaking Windows security auditing. On the other hand, I am baffled as to why Windows itself allows a token to be created for an account that is disabled or locked out. If Cygwin can do it, other programs could too so you're still vulnerable. -- Sam Edge -- 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: Windows to Cygwin username mapping: Domain before local account when duplicate name?
On 14/02/2019 23:47, Bill Stewart wrote: > Consider the case where you have a local account and a domain account > with the same username. > > If you supply just the username to Windows without an authority name, > Windows returns the local account. To get the domain account, you'd > have to specify an authority (e.g. domain\username). > > It seems like Cygwin looks up the domain account first. > > Is this correct, or am I missing something? Is this by design? > > Thanks, > > Bill https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how explains in more detail. -- Sam Edge -- 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
Cygserver functionality in UG
Hi Cygwin UG maintainers. Might it not be a good idea to mention the cygserver ntsec caching functionality in the section https://cygwin.com/cygwin-ug-net/using-cygserver.html#what-is-cygserver with a cross-reference? I'd submit a patch but I'm a bit busy this morning and am not familiar with the web site source tree. I'll try to take a look next week if one of you stout fellows hasn't done it. -- Sam Edge -- 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
Dependency issues in setup.ini.
Hi all. I've been developing a Python package that can interrogate and manipulate local package caches (the directories where setupXXX.exe keeps its downloads) and installation databases (from Cygwin /etc/setup/installed.db files) with a mind to pruning, merging and reporting in the spiript of Michael A. Chase's 'clean_setup' utility but as a scriptable tool set rather than a stand-alone utility. It's not production ready yet but it's already flagged up some issues. For example we have lots of dependency loops in the 'requires' fields in setup.ini - even to the point that some packages depend upon themselves! And also we have some dependency omissions. For example, mintty doesn't depend upon anything - it has no requires field. Surely, every binary package should depend at least upon 'cygwin'? Is this a known issue or should I report in more detail? -- Sam Edge -- 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: Dependency issues in setup.ini.
On 29/09/2017 23:39, Steven Penny wrote: > On Fri, 29 Sep 2017 21:16:17, "Sam Edge (Cygwin)" wrote: >> For example we have lots of dependency loops in the 'requires' fields in >> setup.ini - even to the point that some packages depend upon themselves! > > It is the job of the package manager to detect and avoid such loops. > No database > is perfect - it is up to the good programmer to account for an deal > with problem > data > > Thanks for the clarification. Okay. Once I've written some code to unpick which packages are erroneously creating the loops I'll report back. Next question - :-) - should I report here or in cygwin-apps? At the risk of getting a SHTDI response, perhaps part of the release process for setup.ini should include a topological sort on '@ package'/'requires: package ...' pairs to flag up such issues? :-D -- Sam Edge -- 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: newlib-cygwin.git repository: Switching "master" to "main"
On 13/01/2023 11:55, Corinna Vinschen via Cygwin wrote: > Hey folks, > > In the light of recent discussions, and following other projects already > having done this step, we changed the name of the "master" branch in > the newlib-cygwin.git upstream repository to "main". > > If you fetched from upstream in the last two days, you might already > have noticed that an "origin/main" branch suddenly showed up, but your > "master" branch still worked as before. > > The reason is that we also added a symbolic reference upstream, so that > "origin/master" points to "origin/main". Both "branches" are now > constantly kept in sync upstream. > > Therefore, you can continue your work on "master" without disruption, > if you prefer to do so. > > However, on the client side, the "master" and "main" branches are > treated as two distinct branches. If you work on your local "main" > clone and commit a patch, it's not keeping your local "master" branch in > sync. After pushing your change upstream, though, the upstream idea of > "main" and "master" is, again, the same. After fetching from upstream, > the patch will show up in both tracking branches, "origin/main" as well > as "origin/master", so pulling on both local branches will show the same > tree. > > Having said that. Ideally you only use one of the branches locally > to avoid any confusion: > > - If you prefer to work in "master", just continue to do so and don't > create a local "main" branch tracking "origin/main". > > - If you prefer to work in "main", checkout "origin/main" as "main" and > delete your local "master" branch. > > > Have fun, > Corinna > > While I can understand sensitivity over the word 'slave' this is taking things too far in my opinion. I just conducted a quick poll of my Afro-Caribbean & other non-Caucasian workmates who all express the same sentiment. There is only one use case that relates to slavery. There are dozens that do not. Are we supposed to stop using all of them? The git usage is not to do with master/slave relationship anyway. See https://www.merriam-webster.com/dictionary/master, for example:- * "In Casablanca, I am the master of my own fate." * "She is a master carpenter." * "He is a master of the violin." * "The professor is the master of the college." * "The maid has a master key to all the hotel rooms." People are enduring slavery all over the world right now - here in the UK & USA as well as elsewhere. Not using the words does not stop it happening. Well, it's a fait accompli on the Cygwin repos. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: exe in path directory, "command not found"
On 15/03/2023 03:00, WyntrHeart via Cygwin wrote:
I've added /cygdrive/c/program\ files/notepad++ to my path in .bash_profile,
double checking with echo to make sure that the directory is in the path. But
when I type "notepad++.exe" or "notepad++" I get "bash: notepad++: command
not found". I did restart the terminal before testing to make sure that
.bash_profile was loaded and path was updated. Is there something I'm doing
wrong here or is this a bug?
As per René & Eliot but anyone who uses Notepad++ a lot from Cygwin might be
interested in the attached script which can be put in /etc/profile.d/ or
sourced from your .bashrc. It creates a shell function 'npp' that parses the
command line and translates pathnames to Windows format before passing to
Notepad++. It adds a --wait argument to cause the caller to wait on Notepad++
instance exiting before returning.
The second script ('npp') provides a wrapper around the first for POSIX programs
looking for an executable e.g. git commit message editor etc.
I've done the same for kdiff3 if anyone wants them.
--
Sam Edge
#!/bin/bash
#
# Script to add an "npp" function to invoke Notepad++ to a bash shell session.
#
# $Id: _91.npp.sh 446 2020-12-21 14:05:26Z samedge $
#
# Uses bash-specific extensions.
[ "x${BASH_VERSION}" = "x" ] && return 0
function npp {
[[ -z "${SSH_CLIENT-}" ]] || { echo 'Appear to be running via secure shell
- cannot launch Windows GUI executables.' 1>&2 ; return 255 ; }
if [[ -n "${DISPLAY-}" ]] ; then
local -r display_host="${DISPLAY%:*}"
if [[ -n "$display_host" && "$display_host" != "localhost" &&
"$display_host" != "127.0.0.1" ]] ; then
{ echo 'Appear to be running from a remote X client - cannot launch
Windows GUI executables.' 1>&2 ; return 255 ; }
fi
fi
local exe=
if test -v _NOTEPAD_PLUS_PLUS_EXE && [ -x "$_NOTEPAD_PLUS_PLUS_EXE" ] ; then
exe="$_NOTEPAD_PLUS_PLUS_EXE"
else
local -a path=()
test -v PROGRAMFILES && path+=("$PROGRAMFILES")
test -v ProgramW6432 && path+=("$ProgramW6432")
path+=("$(cygpath --windows -F 42)") # :NOTE: Work-around for parsing
"ProgramFiles(x86)" as a variable name - bash chokes!
path+=('C:\Program Files')
path+=('C:\Program Files (x86)')
local dir
for dir in "${path[@]}"
do
if [[ -n "$dir" ]] ; then
local candidate
candidate="$(cygpath --unix --absolute --
"$dir")/Notepad++/notepad++"
#candidate="$dir\\Notepad++\\notepad++.exe"
if [ -x "$candidate" ] ; then
exe="$candidate"
break
fi
fi
done
[[ -n "$exe" ]] || { echo 'Cannot find Notepad++ Windows executable.'
1>&2 ; return 255 ; }
export _NOTEPAD_PLUS_PLUS_EXE="$exe"
fi
local -i dry_run=0
local -i next_is_not_filename=0
local -i next_is_optarg=0
local wait=
local -a argv=()
local arg
for arg in "$@"
do
if [[ "${arg:0:1}" == '-' ]] && (( ! next_is_optarg )) ; then
case "$arg" in
--dry-run )
arg=
dry_run=1
next_is_not_filename=0
next_is_optarg=0
;;
--wait )
wait="--wait"
arg="-multiInst"
next_is_not_filename=0
next_is_optarg=0
;;
--help | -multiInst | -noPlugin | -nosession | -notabbar | -ro
| -systemtray | -loadingTime | -alwaysOnTop | -openSession | -r | -quickPrint )
next_is_not_filename=0
next_is_optarg=0
;;
-l* | -L* | -n* | -c* | -p* | -x* | -y* | -qn* | -qt* |
-qSpeed* )
next_is_not_filename=0
next_is_optarg=0
;;
-qf* )
next_is_not_filename=0
next_is_optarg=0
arg="-qf$(cygpath --windows --absolute -- "$(realpath
"${arg:3}")")" || return $?
;;
* )
next_is_not_filename=0
next_is_optarg=0
;;
esac
else
if (( ! next_is_not_filename )) ; then
Re: mintty window border?
On 25/08/2023 08:18, Backwoods BC via Cygwin wrote: > On Thu, Aug 24, 2023 at 10:54 PM Gary Johnson via Cygwin > wrote: >> >> On 2023-08-25, Thomas Wolff via Cygwin wrote: >>> >>> >>> Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin: On 2023-08-24, Backwoods BC via Cygwin wrote: > On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin > wrote: >> This is an update to a question I had a couple of years ago >> https://cygwin.com/pipermail/cygwin/2021-April/248367.html >> >> Windows 11 now has an "accent color" option under >> Settings/Personalization/Colors that adds a thin (1px?) border around >> all windows, in a user-selectable color. This definitively eliminates >> the problem seen with overlapping mintty windows that have a dark grey >> or black background (where the shadow isn't visible). >> >> Just FYI >> >> -- >> Jim Garrison >> j...@acm.org > This is also true for Windows 10, although I may have had to > explicitly enable it (I don't remember). It's in the same place on Windows 10. I just enabled it. Thank you both! >>> But it adds the thin border only to the foreground window... >>> Thomas >> >> Yes, it's not as good as having a border around all windows all the >> time, or around just mintty and gvim windows, but it is so much >> better than nothing at all, or so it seems so far. >> >> Regards, >> Gary > > I get borders around both active and inactive windows, but then I've > spent hours (probably days) messing with registry values in an attempt > to gain the kind of UI control that was built into XP. I don't know > which change I made that gave me borders, but it is possible. > > Any combination of these changes may have done it -- or none of them > (I changed a lot of things): > [snip] In Windows 10, I've managed to get inactive window title bars white with a dark accent and active dark with a white accent colour around without resorting to registry hacking. I'm using a solid black background, 'Light' colour setting and auto-selected accent colour in Preferences. I've also enabled the accent colour on title bars and window borders checkbox. I still have problems with non-compliant "I'll draw it myself" apps that don't use the stock furniture but it works for mintty at least. I'm baffled as to why a UI designer would introduce a feature that makes it difficult if not impossible to see the edges of windows in the first place but that's Microsoft all over. :-S -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...
On 24/01/2024 06:33, Cedric Blancher via Cygwin wrote: > Does /usr/bin/cp in Cygwin copy holes correctly Yesterday, within the 'ware, I saw some bytes that weren't there! They weren't there again today, They'd better not just go away. -- Sam Edge (with apologies to Willian Hughes Mearns) OpenPGP_0x8AC2CEBF54528E30.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin a bit slow
On 10/04/2024 11:34, Christian Franke via Cygwin wrote: J M via Cygwin wrote: ... Specifically for this problem, I have investigated the problem and can be related to pipes and antivirus. Specifically while true do echo ABC | grep AAA done It makes the cpu of that antivirus go up. This is as expected because malware scanners hook into Win32 API's CreateProcess*() calls which are also used by the fork()/exec() emulation of Cygwin. Each run of 'grep' above uses at least two CreateProcess*() calls. This is very true and depends greatly on the AV being used. I find Trend is particularly bad, even if you exclude all the Cygwin directories and directories of files being accessed. Somehow, the way the hooks are implemented stalls process creation and file open in ways that Windows Defender does not. This is particularly noticeable when using Cygwin-based build tools - build times generally increase at least 10-fold after installing Trend. On one job, I wasted a lot of time and client's money collecting logs for Trend to analyse to no avail. I think the product is basically very badly written. The fact that it creates dozens of processes with hundreds of threads just to do AV scanning does not fill me with confidence! Wherever possible, I remove third-party AV from Windows machines and install group policy to enforce Windows Defender and malware detection in the browser and/or a proxy & the email server instead. Saves a lot of CPU cycles. :-) -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin a bit slow
On 12/04/2024 19:01, J M via Cygwin wrote: Hi, For me not use AV or disable parts is not an option... Then, if AV is inspecting the CreateProcess, these processes can be known the path of these process? [Please bottom post in Cygwin mailing lists. TIA] I'm not suggesting you don't use a real-time AV scanner. I'm suggesting that Windows Defender is the best one to avoid slowing your Windows PC down in general and especially with Cygwin. (FYI In independent tests, its detection rate is very much as good as Trend, AVM, McAfee etc. as well, so you save money & maintenance time without losing protection to boot.) As I said, with Trend and other badly-written AV services, simply excluding an executable or directory does not prevent the slow down. In some cases even 'disabling' the AV using its UI does not either, probably because this doesn't actually remove the hooks. Again, I recommend removing all third-party AV and using Defender (and Smart Screen, Safe Browsing etc. in your browser) if you have control over your PC. If you're locked down, convince your IT manager about the cost (purchase & your time waiting for the PC) savings of doing so. (Good luck with the last - IT managers are often petty empire builders who don't like taking advice even when it's good & saves money. I know - I have been one in past times!) -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin runs three instances of rsync.exe at the same time
On 18/06/2024 16:03, asdffdsa6132 via Cygwin wrote: hello, thanks, first time poster, sorry if i mis-posted. when in run rsync.exe, in task manager, i see three instances running at the same time. in five years, my backup script runs native windows apps such as rclone.exe, restic.exe, fastcopy.exe, 7z.exe and never had this happen. now, i added rsync.exe via cygwin to the script and can see three instances at the same time??? thanks much for cygwin, david tasklist /fi "imagename eq rsync.exe" Image Name PID Session Name Session# Mem Usage = === rsync.exe 26804 Console 1 9,132 K rsync.exe 16744 Console 1 8,204 K rsync.exe 7796 Console 1 7,228 K This is how rsync works. The executable forked from the command line runs up two communicating child processes to handle the 'from' and 'to' ends of the transfer. If you are using rsync across the network, one of the children is created on the other computer, either via an rsync daemon process or via remote shell, usually ssh. The documentation for rsync explains this. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin runs three instances of rsync.exe at the same time
On 19/06/2024 07:09, Sam Edge via Cygwin wrote: This is how rsync works. The executable forked from the command line runs up two communicating child processes to handle the 'from' and 'to' ends of the transfer. I forgot to say, this is how rsync works on any platform such as Linux or OS X or whatever, not just Cygwin. https://download.samba.org/pub/rsync/rsync.1 -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath and star character
On 15/07/2021 00:07, Tomas Jura via Cygwin wrote:
Hi
My use case is building the CLASSPATH environment variable for java.
Like:
export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory/*' )"
CLASSPATH can contain the star character at the end on Windows.
Example C:\Apps\java\lib\* , which means something different then just
C:\Apps\java\lib, ie. the star is necessary there.
Tomas
So do:
export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory')\*"
If you pass the asterisk to cygpath it will naturally consider it to be
a character in a pathname and give you the equivalent Windows path that
Cygwin would construct using the open() syscall. This is cygpath's
purpose, after all!
--
Sam Edge
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: objects created in a dir w/cygwin mangled perms; inherit no-access
On 15/07/2021 08:02, L A Walsh wrote: On 2021/07/07 11:43, Andrey Repin wrote: Sorta, actually the cygtree mounted at 'C:\'. Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. If you have ever boot to a rescue system running from your hard drive -- you have the choice of using all your cygwin tools to recover your system, or to just use Windows tools. After wading through the unsolicited self-congratulation a few observations. 1. You want support from the Cygwin community for problems you're having despite having installed it in a way that is expressly discouraged. (https://cygwin.com/faq.html#faq.setup.c) Good luck with that. 2. You've not bothered to search the archives or even read the manual, specifically https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files but instead immediately assume a flaw in the code. Not very scientific ... or polite. (By the way, the permission workaround is another good reason for not installing in system root if advice from the authors of Cygwin - Corinna et al - isn't enough for you.) 3. Installing Cygwin under, say, C:\cygwin64 does not prevent you from using it for recovery. PEBCAK -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: META: Fix the signup procedure?
On 12/08/2021 08:18, Russell VT via Cygwin wrote: > >> Moderation is an option but I doubt anyone really wants >> to moderate every message here. >> > > Can't say I would disagree, though back it the time, I've seen teams easily > handle higher traffic lists with a pretty small moderation team. Sounds like an offer to me. Thanks Russell. ;-) -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: objects created in a dir w/cygwin mangled perms; inherit no-access
On 23/08/2021 20:31, L A Walsh wrote: > > On 2021/07/15 01:23, Sam Edge via Cygwin wrote: >> (By the way, the permission workaround is another good reason for not installing in system root if advice from the authors of Cygwin - Corinna et al - isn't enough for you.) > --- > Except that at one point, most of the cygwin developers installed cygwin at '/'. That you don't know that shows how long you've > been using cygwin. For the record, I've been using Cygwin for twenty years or more. For that entire period the recommendation has been not to install in C:\ or the root of any other drive. (I've been using UNIX since 1983 by the way and Windows since version 3.0 not that it makes any difference to the discussion.) > I have other reasons for my setup. My windows system has most > of my files on a remote, linux system. Which can be accessed using //host/path (using S4NFS or SMB) or via Cygwin fstab mounts regardless of where Cygwin is installed locally. > When I'm using the linux > shell, for example, I can bring up explorer for the directory I'm > in by typing 'explore [opt. path]'. My Doc dir, among others is the > same on Windows as on Linux ~/Documents or /d/. If I'm running > a prog on linux, and it asks for a browser, it launches my browser > on Windows. You're not using a Linux shell. You're using a POSIX-like shell compiled for Cygwin. It's different. For example '//path' on Cygwin accesses remote filesystems whereas on Linux it doesn't. If you're running a program on Linux it'll launch whatever it is configured to launch. If you're running a Cygwin program it'll do the same, which with appropriate use of cygpath can launch Windows Explorer (explorer.exe) or your browser. For example my EDITOR variable launches Notepad++ and 'git difftool' launches Windows native KDiff3 and they work for any Cygwin path not just my C drive, converting to Windows when assembling the command line to pass to the native applications. I think Andrey covered the rest of your arguments fairly comprehensively. -- Sam Edge -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 07/09/2021 23:44, Ken Brown via Cygwin wrote:
>
> MS can't add a new named field to a documented struct without
breaking a lot of code. I think it's extremely unlikely that they would
do that. On the other hand, I think it's very likely that a reader of
the Cygwin code would be confused by code that initializes a struct to 0
prior to assigning a value to every member.
Hi Ken.
It is common practice when following a coding standard (especially those
for safety or security sensitive code) to initialize each and every
automatic C/C++ variable at the point of definition even if it is later
assigned a value. The '= {0}' mechanism for structures is a common way
of ensuring this is the case for all fields in a structure and should be
familiar to most developers.
This ensures deterministic behaviour instead of bugs that come and go
depending upon what was on the stack or in the register before the
variable is used. It also helps when reviewing code.
A compiler or static analyser cannot always determine whether a variable
is used before it's assigned so getting into the habit of doing this
saves a lot of grief down the line, as demonstrated by this thread!
--
Sam "Here Endeth The Lesson" Edge
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: possible snprintf() regression in 3.3.2
On 18/11/2021 14:27, Corinna Vinschen via Cygwin wrote: On Nov 18 16:11, Noel Grandin via Cygwin wrote: On 2021/11/18 3:19 pm, Corinna Vinschen via Cygwin wrote: My patch raised NDEC from 43 to 1023 to allow aproximately the same number of digits as glibc. Newlib strives to support embedded targets and bare metal. Some of them are lucky if they have a stack size of 1K. The outbuf buffer is created on the stack, so I used ndigits to save stack space. While that patch fixes the reported problem, it will make users of smaller-than-Cygwin targets pretty unhappy. A workaround would be to malloc outbuf instead. Given that printf printf is often performance sensitive, and using malloc there would likely be significantly slower. Possibly use alloca() to allocate only the necessary amount on stack? That's kind of what the current code does. But that's apparently the problem. The necessary amount is only known to the current algorithm while populating outbuf already. So before my patch, outbuf had a constant size, but it was size restricted. Seems unlikely that embedded systems would be printing values that needed such large space anyway. Perhaps that's a workaround: Use a constant buffer size, but use NDEC = 1023 only on Cygwin for the time being, something like NDEC = 64 otherwise... Corinna Hi all. I use newlib on embedded with threading libs that have predetermined fixed thread stack sizes. While we tend to have more RAM than in former times we also have multiple thread stacks. Use of alloca() or variable length automatic arrays makes me wince especially in code I might not be able to avoid calling which is often the case with XXXprintf() in third-party libraries' debug output. I'd usually rather take the performance hit from using heap instead of having to make all my stacks bigger. Just my two penn'orth. Cheers. -- Sam -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
