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

2007-05-04 Thread Eric Blake
-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 
 decimaldecimal [ 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
000 0d 1b 5b 2d 31 43 78 78 78 0a..[-1Cxxx.
012

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 [EMAIL PROTECTED]
-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-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


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

2007-05-04 Thread Micah Cowan
Eric Blake wrote:
 #$ 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.

Using -e isn't portable shell either, as POSIX requires echo to
recognize no options, but instead treat them as arguments. printf would
be a much more portable solution (still escaping or quoting backslashes,
as Eric suggests).

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils