Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: slinky.cs.nyu.edu: pechtcha owned process doing -bs Date: Tue, 12 Nov 2002 12:44:36 -0500 (EST) From: Igor Pechtchanski Reply-To: cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com Subject: RE: Missing commands/incorrect behaviour after update In-Reply-To: <5.1.0.14.2.20021112075629.01ff0220@pop3.cris.com> Message-ID: Importance: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 12 Nov 2002, Randall R Schulz wrote: > Michael, > > At 05:28 2002-11-12, Eriksson, Michael wrote: > >Max, > > > > Hi, > > > > > > > > ... > > > > > > Re install the relevant packages. > > > http://cygwin.com/packages/ if you don't > > > know which the relvant packages are. > > > >I have looked there already, but it is not obvious to me what packages > >would be relevant. (Neither from the original listing nor from the 206 > >matches for a "cat"-search.) > > Perhaps the package search page would benefit from a hint about appending > ".exe" when looking for command names that are (expected to be) binary > executables? Of course, doing so would prevent seeing scripts and symlinks. Try searching for "bin/cat". Randall is right, though, this would be a good thing to have as a hint on the search page... > > > > 2) A newly created directory can only be entered after chmod 700 > > > > (or similar). This is (I believe) consistent with my umask of 122, > > > > but a) inconsistent with previous behaviour, b) bloody stupid. > > > > > > Ok... You ask (set your umask) your computer to do something, and then > > > expect it do to something else? > > > Analogous situation: > > > $ touch foo bar > > > $ rm foo > > > > > > "No, stupid computer, you should have realized I wanted to delete bar > > > instead!" > > > >No need to get sarcastic. I have not worked extensively with a "real" > >unix system for years, but I do not recall this problem. In particular: > >To have reasonable default settings for directories I must include > >1 in the chmod-code, but for files exclude it? Hm... > > I don't really see why you want a execute bit in your umask. Programs that > create files typically either use 0666 or 0777 for the new file's mode and > they do the latter only when they're creating executable files, so putting > an execute bit in your umask is basically second-guessing the software. As > you probably know, directories must bear an applicable execute bit if their > contents are to be examined by the "kernel" for opens, creates or cd's, etc. Correction. The execute bit is needed to *access* the contents of the directories. The contents can be examined (i.e. the directory can be read) with just the read bit on. For example (on Linux): $ /bin/mkdir lstest $ echo aaa > lstest/aaa $ /bin/chmod 644 lstest drw-r--r-- 2 igor root 4096 Nov 12 11:52 lstest $ /bin/ls lstest aaa $ /bin/ls -l lstest /bin/ls: lstest/aaa: Permission denied total 0 $ /bin/cat lstest/aaa /bin/cat: lstest/aaa: Permission denied $ /bin/chmod 311 lstest $ ls -ld lstest d-wx--x--x 2 igor root 4096 Nov 12 11:52 lstest $ /bin/ls lstest /bin/ls: lstest: Permission denied $ /bin/cat lstest/aaa aaa $ It's interesting to note that the "ls -l" above fails because it has to stat the *files* in the directory, as well as read the directory contents. This, of course, doesn't work the same way if you're root :-D Or, as it turns out, if you have admin privileges on your NT machine. > > > As to why the behaviour has changed, ntsec is now on by > > > default in recent Cygwin DLLs. > > > >Speculating that ntsec is means NT security, how do I/can I turn it off? > >I do almost all security handling through Windows Explorer anyway, > >since the incompatibilities have caused me to many problems. > > Ntsec is documented so speculation is really unnecessary. The switch to > having it on by default was announced in the release notes for the Cygwin > package update that included it and because of the change has come up in > several messages on the Cygwin list since then. > > > > > 3) I have sporadic occurences of being automatically put in input mode > > > > (instead of the correct normal mode) when going through the history > > > > with the arrow keys or j/k. (Using, of course, vi command line > > > > editing.) > > > > > > No idea - I don't use vi command line editing. > > > >Your loss entirely :-) > > There have been repeated reports of problems with Vi-mode line editing in > BASH. In particular, I seem to recall that striking keys that send escape > sequences are a problem. Apparently, the initial ESC from the sequences > does not initiate a time-out before it is interpreted as an isolated > command- or input-mode-terminating escape. This should be fixed in the latest bash. > Even though I'm a died-in-the-wool Vi user, I stick to Emacs mode in BASH. > But then, I make only rudimentary use of BASH line editing and other > readline features. Same here, FWIW. > >Michael > > Randall Schulz > Mountain View, CA USA Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51 -- 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/