bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BKR01- problems detected with: chmod, xterm and linux-console


From: Eric Blake
Subject: Re: BKR01- problems detected with: chmod, xterm and linux-console
Date: Fri, 04 May 2007 13:50:34 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Your mail client appears to add a space after every -, which made it
somewhat awkward to read.

According to benjamin kravanja on 5/4/2007 5:30 AM:
> Hallo,
> 
> 1 - seems to be a critical bug in chmod,
>     if superuser flags were set, you can not reset them by using chmod 
> <decimal>decimal [ file | dir | ... ]

chmod does not take decimal arguments; it takes octal.

This behavior is intentional, and is POSIX-compliant.  Read the NEWS for 6.0:

  chmod, install, and mkdir now preserve a directory's set-user-ID and
  set-group-ID bits unless you explicitly request otherwise.  E.g.,
  `chmod 755 DIR' and `chmod u=rwx,go=rx DIR' now preserve DIR's
  set-user-ID and set-group-ID bits instead of clearing them, and
  similarly for `mkdir -m 755 DIR' and `mkdir -m u=rwx,go=rx DIR'.  To
  clear the bits, mention them explicitly in a symbolic mode, e.g.,
  `mkdir -m u=rwx,go=rx,-s DIR'.  To set them, mention them explicitly
  in either a symbolic or a numeric mode, e.g., `mkdir -m 2755 DIR',
  `mkdir -m u=rwx,go=rx,g+s' DIR.  This change is for convenience on
  systems where these bits inherit from parents.  Unfortunately other
  operating systems are not consistent here, and portable scripts
  cannot assume the bits are set, cleared, or preserved, even when the
  bits are explicitly mentioned.  For example, OpenBSD 3.9 `mkdir -m
  777 D' preserves D's setgid bit but `chmod 777 D' clears it.
  Conversely, Solaris 10 `mkdir -m 777 D', `mkdir -m g-s D', and
  `chmod 0777 D' all preserve D's setgid bit, and you must use
  something like `chmod g-s D' to clear it.

> 
> 2 - bug in positional esc- seuqence interpreting
>     under console -  "linux" and "xterm

This is not a bug in coreutils.  Also, are you sure you are using
coreutils' echo, and not the shell builtin?

> #    $ echo - e "\015\033[- 1Cxxx" starts string "xxx" at position 0, ok

Using "\015" as the argument to echo is not portable shell; you should use
"\\015" or '\015' instead.

> #    $ echo - e "\015\033[0Cxxx"  starts string "xxx" at position 2, not ok

To prove that the bug lies elsewhere (probably in xterm), you can do:

/bin/echo -e '\015\033[-1Cxxx' | od -tx1z
0000000 0d 1b 5b 2d 31 43 78 78 78 0a                    >..[-1Cxxx.<
0000012

Sure enough, all of the requested characters were output correctly; it is
now up to the terminal how they are interpreted.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGO46J84KuGfSFAYARAmDcAKDIGrken1YjxN7I6hg2/1j++8NpXwCaAz6a
ui8H1zZseuni8Poro9cVLNE=
=v6LG
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]