This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Missing commands/incorrect behaviour after update


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]