Missing commands/incorrect behaviour after update

Randall R Schulz rrschulz@cris.com
Tue Nov 12 09:44:00 GMT 2002


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.


> > > 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
> > <computer deletes 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.


> > 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.

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.


>Michael


Randall Schulz
Mountain View, CA USA


--
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/



More information about the Cygwin mailing list