Missing commands/incorrect behaviour after update

Missing commands/incorrect behaviour after update

[Eriksson, Michael]

Hi,

after updating my cygwin installation on Friday (with repeated
re-updates on Monday) I have several problems.

1) Several commands (at least cat and fold) are missing, even if the man pages
are still there. Both the download and installations where (eventually)
made with everything available through the installer.

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.

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

Can anyone explain these strange problems? What can I do to get a properly
working setup?

In case of plattform dependencies I use Windows 2000 SP2.

And yes, I failed to make a backup of the existing older downloaded files.


Grüsse,

Michael

--
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: Missing commands/incorrect behaviour after update

[Max Bowsher]

Eriksson, Michael <Michael.Eriksson@bauer-partner.com> wrote:

> Hi,
>
> after updating my cygwin installation on Friday (with repeated
> re-updates on Monday) I have several problems.
>
> 1) Several commands (at least cat and fold) are missing, even if the
> man pages are still there. Both the download and installations where
> (eventually) made with everything available through the installer.

Re install the relevant packages.
http://cygwin.com/packages/ if you don't know which the relvant packages
are.

> 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!"

As to why the behaviour has changed, ntsec is now on by default in recent
Cygwin DLLs.

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


Max.



--
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: Missing commands/incorrect behaviour after update

[Eriksson, Michael]

Max,
> > Hi,
> >
> > after updating my cygwin installation on Friday (with repeated
> > re-updates on Monday) I have several problems.
> >
> > 1) Several commands (at least cat and fold) are missing, even if the
> > man pages are still there. Both the download and installations where
> > (eventually) made with everything available through the installer.
> 
> 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.)

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

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

> > 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 :-)


Michael 

--
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: Missing commands/incorrect behaviour after update

[Randall R Schulz]

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/

RE: Missing commands/incorrect behaviour after update

[Igor Pechtchanski]

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

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@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/

RE: Missing commands/incorrect behaviour after update

[Randall R Schulz]

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/

RE: Missing commands/incorrect behaviour after update

[Randall R Schulz]

Michael,

At 09:52 2002-11-12, Eriksson, Michael wrote:

>Randall
> >
> > 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.
>
>Thanks for the tip. Due to timeouts I have not been able to check it, but
>I will give it a new shot tomorrow.
>I would extend the hint to an explanation of the principles behind the
>search. (Free-text, database with module content, whatever.)

A patient browser is necessary when accessing this page...


><snip>
> > 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.
>
>Well, 0666 does not seem like a good idea, since it gives everyone the
>right to change the files. Of course the main use of umask is to restrict
>access from group and other.

It's a very good idea and has been "the right way" (or, to use a 
now-archaic phrase, "The Unix Way (tm)") ever since version 7 Unix when 
umask was introduced. The whole point of writing the code to give new files 
full access (0666 or 0777) is so that the user is in complete control by 
virtue of the "umask."

You do understand that the umask value is "subtracted" (bit-wise) from the 
file mode specified by the program creating the new file system entity, right?


>As for why I include the 1: It was the official recommendation when I started
>university (1994), and I have sofar never had any problems with it.
>I will try without 1 for a while.

People make lots of bad recommendations about how to use Unix. This appears 
to be one of them. It serves no useful purpose other than to make things 
break, as you've seen. The old default of "nontsec" was protecting you from 
that failure up until recently when ntsec was switched on by default.

The usual recommendation is 022 or 02, depending on the nature of your user 
community and how groups are used in the overall access control strategy.


> > 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.
>
>On this point I must admit to never having paid much attention to Cygwin
>lists etc. Normally I download a new version every 3-6 months and that's it.
>My bad...

That's not an advisable strategy for Cygwin. Occasionally there are upgrade 
procedures that if ignored render your system variously crippled. It's rare 
and naturally package maintainers try to avoid it, but it's occasionally 
necessary.

Frankly, I know of no software for which upgrades can usefully be applied 
blindly. Even bug-fix releases can have negative repercussions in some cases.


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

RE: Missing commands/incorrect behaviour after update

[Eriksson, Michael]

Randall
<snip>
> >Well, 0666 does not seem like a good idea, since it gives 
> everyone the
> >right to change the files. Of course the main use of umask 
> is to restrict
> >access from group and other.
> 
> It's a very good idea and has been "the right way" (or, to use a 
> now-archaic phrase, "The Unix Way (tm)") ever since version 7 
> Unix when 
> umask was introduced. The whole point of writing the code to 
> give new files 
> full access (0666 or 0777) is so that the user is in complete 
> control by 
> virtue of the "umask."
> 
> You do understand that the umask value is "subtracted" 
> (bit-wise) from the 
> file mode specified by the program creating the new file 
> system entity, right?

No, I was actually under the impression that is was substracted
from 777. Thank you for setting me straight.
(That comes working with windows...)

<snip>

Michael

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