GNU logs - #29069, boring messages

Message sent to bug-coreutils@HIDDEN:

Subject: bug#29069: info coreutils file permissions: improvements/bug-report
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 30 Oct 2017 18:35:01 +0000
Resent-Message-ID: <handler.29069.B.150938849310226 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 29069 <at> debbugs.gnu.org
Message-ID: <59F78DAE.9070305@HIDDEN>
Date: Mon, 30 Oct 2017 21:38:06 +0100
From: kalle <kalle@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

hello,
here some improvement proposals/bug report on info coreutils file
permissions:

-in my opinion it would be good to explain the general idea bihind the
file permissions a bit more. what the issues are etc. Elese one doesn't
really understand, what all the detailed fuss is about.
-why is running a file considered different  from reading one? Fact is,
that this point underlies the concept of symbolic mode with it's `rwx'.
-27.1,end of the first section: add the sentence "They have a different
meaning, according to wether they are directories or not"
-27.2.4, part "or already had execute permission": had execute
permission for which user category? for the one in question or for any?
-explain more fundamentally the relationship between file permission
rights and the rights of the corresponding directory , for example
regarding to deletion: who has the right to delete file /b/a? users with
writing permission on a AND those withrmission on b?
27.4: wouldn't it be better to talk about 'operators _in_ numeric mode'
rather than from an 'operator numeric mode', since "numeric mode" is an
atrribute?
-27.3: is there an info/man-document, where binary, octal, hex-numbers
are explained? If, it should be referred to. If not, shouldn't there be
one (and where would it fit in? ) ?-- I could write the text...Since
this documentation assumes the knowledge of it..
-27.5: it is said, that "a command like `chmod' does not affect the
set-user-id, unless [=E2=80=A6] sets them in a numeric mode".But also, th=
e
example states that `chmod 0755' or `mkdir -m 0755' doesn't change
set-user/group-id- bits. For me, this doesn't fit together,since the `0'
in `0755' explicitly sets all special mode bits to zero.
-27.5,last section, it says: "this behavior is a GNU extension". Which
behavior is meant? And if it concerns the whole section 27.5, it should
be put right at the beginning.

greetings,
kalle

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: kalle <kalle@HIDDEN>
Subject: bug#29069: Acknowledgement (info coreutils file permissions:
 improvements/bug-report)
Message-ID: <handler.29069.B.150938849310226.ack <at> debbugs.gnu.org>
References: <59F78DAE.9070305@HIDDEN>
X-Gnu-PR-Message: ack 29069
X-Gnu-PR-Package: coreutils
Reply-To: 29069 <at> debbugs.gnu.org
Date: Mon, 30 Oct 2017 18:35:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-coreutils@HIDDEN

If you wish to submit further information on this problem, please
send it to 29069 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
29069: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D29069
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-coreutils@HIDDEN:

Subject: bug#29069: info coreutils file permissions: improvements/bug-report
Resent-From: Assaf Gordon <assafgordon@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 30 Oct 2017 19:36:02 +0000
Resent-Message-ID: <handler.29069.B29069.150939214216315 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: kalle <kalle@HIDDEN>, 29069 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
References: <59F78DAE.9070305@HIDDEN>
From: Assaf Gordon <assafgordon@HIDDEN>
Message-ID: <30cc4360-5e31-89ef-4840-4e4d5408d14d@HIDDEN>
Date: Mon, 30 Oct 2017 13:35:32 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <59F78DAE.9070305@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

tag 29069 notabug
stop

Hello,

On 2017-10-30 02:38 PM, kalle wrote:
> here some improvement proposals/bug report on info coreutils file 
> permissions:
> 
> -in my opinion it would be good to explain the general idea bihind 
> the file permissions a bit more. what the issues are etc. Elese one 
> doesn't really understand, what all the detailed fuss is about. -why
> is running a file considered different  from reading one? Fact is,
> that this point underlies the concept of symbolic mode with it's 
> `rwx'. -

There is a trade-off between being a full-blown unix tutorial and a
manual for coreutils.

There are many good tutorials and guides available in books and online,
e.g. https://wiki.debian.org/Permissions .

To make this discussion more concrete, it would help if you send 
specific patches for the paragraph you'd like to change, with suggested 
wording.

> 27.1,end of the first section: add the sentence "They have a 
> different meaning, according to wether they are directories or not"

Each relevant bullet points in that page end with "... for Directories,
this means [...]".

https://www.gnu.org/software/coreutils/manual/html_node/Mode-Structure.html

> 27.2.4, part "or already had execute permission": had execute 
> permission for which user category? for the one in question or for 
> any?

Any category.

The last sentence in that page says:
"gives all users permission [...]  if anyone could execute them before".

https://www.gnu.org/software/coreutils/manual/html_node/Conditional-Executability.html

> -explain more fundamentally the relationship between file permission
> rights and the rights of the corresponding directory , for example
> regarding to deletion: who has the right to delete file /b/a? users
> with writing permission on a AND those withrmission on b?

I think this is a good suggestion (though perhaps not specific to
coreutils).

We recently had a related discussion about that in 'sed',
where users were surprised that "sed --inplace" can modify a read-only file.
https://lists.gnu.org/archive/html/bug-sed/2017-06/msg00000.html

Similarly on gawk:
https://lists.gnu.org/archive/html/bug-gawk/2015-06/msg00000.html

> 27.4: wouldn't it be better to talk about 'operators _in_ numeric
> mode' rather than from an 'operator numeric mode', since "numeric
> mode" is an atrribute?

(I'll leave this to native English speakers)

 > -27.3: is there an info/man-document, where binary,
> octal, hex-numbers are explained? If, it should be referred to. If 
> not, shouldn't there be one (and where would it fit in? ) ?-- I
> could write the text...Since this documentation assumes the knowledge
> of it..

Not sure this belongs in the coreutils manual,
however if you send a patch that would go a long way towards considering 
it for inclusion.

For comparison, I see that "chmod" manual page in OpenBSD, FreeBSD and
POSIX mention octal code values but do not explain with octal is.
The reader is expected to either use them as-is, or search for more 
details elsewhere.

https://man.openbsd.org/chmod.1
https://www.freebsd.org/cgi/man.cgi?query=chmod
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

 >
-27.5: it is said, that "a command like `chmod' does not
> affect the set-user-id, unless […] sets them in a numeric mode".But
> also, the example states that `chmod 0755' or `mkdir -m 0755'
> doesn't change set-user/group-id- bits.
 >
> For me, this doesn't fit 
> together,since the `0' in `0755' explicitly sets all special mode 
> bits to zero.

There is some subtlety here, which perhaps can be explained better 
(patches are welcomed!).

Setting (=turning on) sticky/setuid/setgid bits using the 4th octal 
digit works as expected (i.e. chmod 4775 DIR).

In GNU's chmod(1), setting the 4th digit to zero *does not* clear those 
bits, it preserves them (i.e. does not change them if they are set).
To clear them, one needs to specify *five* octal digits: 00755.

This is explained in the second paragraph of section 27.5:
"Therefore, a command like chmod does not affect the set-user-ID or 
set-group-ID bits of a directory unless the user specifically mentions 
them in a symbolic mode, or uses an operator numeric mode such as 
‘=755’, or sets them in a numeric mode, or clears them in a numeric mode 
that has **five or more** octal digits."
https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

The last paragraph on said page also mentions:
"The GNU behavior with numeric modes of four or fewer digits is intended 
for scripts portable to systems that preserve these bits; the behavior 
with numeric modes of five or more digits is for scripts portable to 
systems that do not preserve the bits."

The wording could also be improved in section "27.3 Numeric Modes", 
which only mentions this in passing:
   "However, modes of five digits or more, such as ‘00055’,
    are sometimes special. See Directory Setuid and Setgid."
https://www.gnu.org/software/coreutils/manual/html_node/Numeric-Modes.html

> -27.5,last section, it says: "this behavior is a GNU 
> extension". Which behavior is meant?

This refers to the preceding paragraph, dealing with "if you want to 
clear these bits".

The behavior differs from other systems (e.g. FreeBSD),
where "chmod 0775" indeed clears the suid bit.

> greetings, kalle

Thank you for raising these issues.

If you'd like to suggest better wordings, please do send a patches
(preferably one patch for each section/topic).

I'm marking this as "not-a-bug", but keeping it open
until we either improve these items or decide to keep them as-is.

regards,
  - assaf

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 30 Oct 2017 19:35:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 30 15:35:42 2017
Received: from localhost ([127.0.0.1]:42674 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e9FqX-0004Ey-RQ
	for submit <at> debbugs.gnu.org; Mon, 30 Oct 2017 15:35:42 -0400
Received: from mail-io0-f175.google.com ([209.85.223.175]:51091)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <assafgordon@HIDDEN>)
 id 1e9FqV-0004Eh-Ro; Mon, 30 Oct 2017 15:35:40 -0400
Received: by mail-io0-f175.google.com with SMTP id 97so29799126iok.7;
 Mon, 30 Oct 2017 12:35:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=subject:to:references:from:message-id:date:user-agent:mime-version
 :in-reply-to:content-language:content-transfer-encoding;
 bh=Dau0Eq4kQqwa1XLkp0IA0OTK6pETE4pESTY7TFa7Z84=;
 b=raMLc6cWrZmCCmKn1hP8ObDOwaIU2cPep+nZSghmLn4O0MWLFJHqeTwxfSjbQ5ratO
 NQA/wlKRYg3hHgE+eVcmYzag0rNa2/4yOZMKMmi8z47e+dqPFIepf7DGhNOkP62YMiFa
 d4m33ZVTuk7nhLGMuU2Cnzyq2BiAMAcCXi3MIlSwRdNTDyNT4N0+aki9FF3fGwaPy/oS
 JrIJXFeGH+zUigwjn3JyD62sd+gvuAFq1epLtGP5TabA9WHpjWiy2glFRhnLsgTVSbIk
 kyLb5a9obmQ2CV5HKG6bP3cI8qmPuBP8VEbs/z+o8IgHhE32IvWTjWZsXHXYxVAcUILR
 W0mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=Dau0Eq4kQqwa1XLkp0IA0OTK6pETE4pESTY7TFa7Z84=;
 b=pjNKB6t9Ffhb8MItaNnm0ocQi5X9SNxNqMeizcsHnQz7C8ONP+0PKfevgZmH3JEPSc
 s14YrWvnsmfsKv98t6BmVIC0X3wKk9HVOEZ2HVDPBQ9+hEzhyKuUtuUzOX0FWrtQjZuL
 wHeExFSbyEOGbdst3WRpBb3pgNP6V00TjaHFofEBNof7fDVgC3Xdf7vv701uyyFWQN+k
 oVbdPQflLa/d2I9KhKXfOJZ4/2zts/U5AFVafK9kvKwM+o2QlLhmQZFKjFkKlXmXRTUN
 3rAv2K6BKL+KQtShkT0SWRlsyUyknB+nf5Z2J5+Y03Jh5MJl/hJOcpS0TCVtO3PFqeaW
 Tntw==
X-Gm-Message-State: AMCzsaW+PvTVkUc+9KQEuvvqq8QK1UnL1r8eElBPoqMHNMM7bScN+JpC
 Uhz1oj5kR2JhAySpZEhcAzS1EcMq
X-Google-Smtp-Source: ABhQp+TwL+YFv55u+vSPkwg+Rdcy00IrlFPFoY32///fgjVGIBNxk4Y5g03zfSauoV2bbsCnXeAWEg==
X-Received: by 10.36.120.136 with SMTP id p130mr7685444itc.54.1509392133974;
 Mon, 30 Oct 2017 12:35:33 -0700 (PDT)
Received: from [192.168.88.239] (moose.housegordon.com. [184.68.105.38])
 by smtp.googlemail.com with ESMTPSA id s129sm2246825itb.22.2017.10.30.12.35.33
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 30 Oct 2017 12:35:33 -0700 (PDT)
Subject: Re: bug#29069: info coreutils file permissions:
 improvements/bug-report
To: kalle <kalle@HIDDEN>, 29069 <at> debbugs.gnu.org,
 control <at> debbugs.gnu.org
References: <59F78DAE.9070305@HIDDEN>
From: Assaf Gordon <assafgordon@HIDDEN>
Message-ID: <30cc4360-5e31-89ef-4840-4e4d5408d14d@HIDDEN>
Date: Mon, 30 Oct 2017 13:35:32 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <59F78DAE.9070305@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

tag 29069 notabug
stop

Hello,

On 2017-10-30 02:38 PM, kalle wrote:
> here some improvement proposals/bug report on info coreutils file 
> permissions:
> 
> -in my opinion it would be good to explain the general idea bihind 
> the file permissions a bit more. what the issues are etc. Elese one 
> doesn't really understand, what all the detailed fuss is about. -why
> is running a file considered different  from reading one? Fact is,
> that this point underlies the concept of symbolic mode with it's 
> `rwx'. -

There is a trade-off between being a full-blown unix tutorial and a
manual for coreutils.

There are many good tutorials and guides available in books and online,
e.g. https://wiki.debian.org/Permissions .

To make this discussion more concrete, it would help if you send 
specific patches for the paragraph you'd like to change, with suggested 
wording.

> 27.1,end of the first section: add the sentence "They have a 
> different meaning, according to wether they are directories or not"

Each relevant bullet points in that page end with "... for Directories,
this means [...]".

https://www.gnu.org/software/coreutils/manual/html_node/Mode-Structure.html

> 27.2.4, part "or already had execute permission": had execute 
> permission for which user category? for the one in question or for 
> any?

Any category.

The last sentence in that page says:
"gives all users permission [...]  if anyone could execute them before".

https://www.gnu.org/software/coreutils/manual/html_node/Conditional-Executability.html

> -explain more fundamentally the relationship between file permission
> rights and the rights of the corresponding directory , for example
> regarding to deletion: who has the right to delete file /b/a? users
> with writing permission on a AND those withrmission on b?

I think this is a good suggestion (though perhaps not specific to
coreutils).

We recently had a related discussion about that in 'sed',
where users were surprised that "sed --inplace" can modify a read-only file.
https://lists.gnu.org/archive/html/bug-sed/2017-06/msg00000.html

Similarly on gawk:
https://lists.gnu.org/archive/html/bug-gawk/2015-06/msg00000.html


> 27.4: wouldn't it be better to talk about 'operators _in_ numeric
> mode' rather than from an 'operator numeric mode', since "numeric
> mode" is an atrribute?

(I'll leave this to native English speakers)

 > -27.3: is there an info/man-document, where binary,
> octal, hex-numbers are explained? If, it should be referred to. If 
> not, shouldn't there be one (and where would it fit in? ) ?-- I
> could write the text...Since this documentation assumes the knowledge
> of it..

Not sure this belongs in the coreutils manual,
however if you send a patch that would go a long way towards considering 
it for inclusion.

For comparison, I see that "chmod" manual page in OpenBSD, FreeBSD and
POSIX mention octal code values but do not explain with octal is.
The reader is expected to either use them as-is, or search for more 
details elsewhere.

https://man.openbsd.org/chmod.1
https://www.freebsd.org/cgi/man.cgi?query=chmod
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

 >
-27.5: it is said, that "a command like `chmod' does not
> affect the set-user-id, unless […] sets them in a numeric mode".But
> also, the example states that `chmod 0755' or `mkdir -m 0755'
> doesn't change set-user/group-id- bits.
 >
> For me, this doesn't fit 
> together,since the `0' in `0755' explicitly sets all special mode 
> bits to zero.

There is some subtlety here, which perhaps can be explained better 
(patches are welcomed!).

Setting (=turning on) sticky/setuid/setgid bits using the 4th octal 
digit works as expected (i.e. chmod 4775 DIR).

In GNU's chmod(1), setting the 4th digit to zero *does not* clear those 
bits, it preserves them (i.e. does not change them if they are set).
To clear them, one needs to specify *five* octal digits: 00755.

This is explained in the second paragraph of section 27.5:
"Therefore, a command like chmod does not affect the set-user-ID or 
set-group-ID bits of a directory unless the user specifically mentions 
them in a symbolic mode, or uses an operator numeric mode such as 
‘=755’, or sets them in a numeric mode, or clears them in a numeric mode 
that has **five or more** octal digits."
https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

The last paragraph on said page also mentions:
"The GNU behavior with numeric modes of four or fewer digits is intended 
for scripts portable to systems that preserve these bits; the behavior 
with numeric modes of five or more digits is for scripts portable to 
systems that do not preserve the bits."

The wording could also be improved in section "27.3 Numeric Modes", 
which only mentions this in passing:
   "However, modes of five digits or more, such as ‘00055’,
    are sometimes special. See Directory Setuid and Setgid."
https://www.gnu.org/software/coreutils/manual/html_node/Numeric-Modes.html



> -27.5,last section, it says: "this behavior is a GNU 
> extension". Which behavior is meant?

This refers to the preceding paragraph, dealing with "if you want to 
clear these bits".

The behavior differs from other systems (e.g. FreeBSD),
where "chmod 0775" indeed clears the suid bit.


> greetings, kalle

Thank you for raising these issues.

If you'd like to suggest better wordings, please do send a patches
(preferably one patch for each section/topic).

I'm marking this as "not-a-bug", but keeping it open
until we either improve these items or decide to keep them as-is.

regards,
  - assaf

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: info coreutils file permissions: improvements/bug-report
References: <59F78DAE.9070305@HIDDEN>
In-Reply-To: <59F78DAE.9070305@HIDDEN>
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 08 Nov 2017 09:32:01 +0000
Resent-Message-ID: <handler.29069.B29069.151013350222179 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: assafgordon@HIDDEN, 29069 <at> debbugs.gnu.org,  control <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.151013350222179
          (code B ref 29069); Wed, 08 Nov 2017 09:32:01 +0000
Received: (at 29069) by debbugs.gnu.org; 8 Nov 2017 09:31:42 +0000
Received: from localhost ([127.0.0.1]:57567 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eCMhx-0005le-WD
	for submit <at> debbugs.gnu.org; Wed, 08 Nov 2017 04:31:42 -0500
Received: from mail.netzguerilla.net ([217.11.57.120]:35689)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>)
 id 1eCMhw-0005lN-CA; Wed, 08 Nov 2017 04:31:41 -0500
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 432E7100013;
 Wed,  8 Nov 2017 10:31:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([IPv6:2a00:1828:2000:612::25])
 by localhost (sal.netzguerilla.net [IPv6:::1]) (amavisd-new, port 10024)
 with ESMTP id NadeqRnbEfUS; Wed,  8 Nov 2017 10:31:32 +0100 (CET)
Received: from [IPv6:2003:dd:fbf2:e201:219:99ff:fe54:3f58]
 (p200300DDFBF2E201021999FFFE543F58.dip0.t-ipconnect.de
 [IPv6:2003:dd:fbf2:e201:219:99ff:fe54:3f58])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id 7AAED100012;
 Wed,  8 Nov 2017 10:31:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1510133492;
 bh=ssvTpCx9ze9QP6Zn/asdMP8zfCwmA6fK7cU7r2jenUs=;
 h=Date:From:To:Subject:From;
 b=Jjuq+zCRy6hfzG3VV7VtBWvOmkPGdOy9RZhRfdDDSpvVvgX1s9pC1QAi6mlwI7DVs
 h1PReUAvJTU+hwYeT3pLTg7JqTkVQVIY75R9tfAEBzuOMTrKTEnyPRXP4bllqglJy1
 I/B5nV2/o3cB6anER71te5fPin/iw3ADm5sIcOEa79Uo1wXtM1vgzE9Wb0YkQ97acz
 KIvO1r23M1M/ruKoxsnoXpOb3W1KYThaI2rOfBd46UMHfMUrsDbgYc/MuyZzMDxq3b
 YW8ciG7GtMa+dI6y7B75Cd+VGQGdhK9Ex3HdTZGj7HsjWae3sPlVdv++5aE+RpjwhD
 hL7vQxMTteaYQ==
Message-ID: <5A02DCF8.4060200@HIDDEN>
Date: Wed, 08 Nov 2017 11:31:20 +0100
From: kalle <kalle@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

hi,
the parts concerning 27.3 (numeric modes) have been put into a different
e-mail by me.



>On 2017-10-30 02:38 PM, kalle wrote:
>> here some improvement proposals/bug report on info coreutils file
permissions:
>>
>> -in my opinion it would be good to explain the general idea bihind
the file permissions a bit more. what the issues are etc. Elese one
doesn't really understand, what all the detailed fuss is about. -why
>> is running a file considered different  from reading one? Fact is,
>> that this point underlies the concept of symbolic mode with it's `rwx'. -

>There is a trade-off between being a full-blown unix tutorial and a
>manual for coreutils.

I thought that `man' does the short reference part and info was a bit
more detailed. The wiki.debian.org/Permissions-tutorial is even shorter
than this texinfo-document actually is and also doesn't motivate the
permission concept.

>There are many good tutorials and guides available in books and online,
>e.g. https://wiki.debian.org/Permissions .

IMO the advantage of texinfo is, that it is nearly always by the hand
and is a standard documentation. The disadvantage of the
debian-wiki-tutorial is, that it uses a debian-specific platform while
handling general content, thus unnecessarily wasting resources in form
of human time and restricting accessability, in the sense that not all
GNU-users would look at this site.
It by the way has a wrong description about unsetting special mode bits
by doing e.g. `chmod '0755'' (see at "Case 4"), which I will correct as
soon as possible -> more users, less mistakes..

What do YOU think should be the character of an info-file?

>To make this discussion more concrete, it would help if you send
specific patches for the paragraph you'd like to change, with suggested
wording.

As it's about the motivation of the concept I would prefer to not help
out with a patch since I myself am a learner.

>> 27.1,end of the first section: add the sentence "They have a
different meaning, according to wether they are directories or not"

>Each relevant bullet points in that page end with "... for Directories,
>this means [...]".

I think it is better to write this before the bullet points to make it
clear, that the concept  of "read"/"write"/etc. is different whether it
is a regualar file or a directory rather than you have to interprete
these terms differently according to whether the target file is a
regular file or a directory.



>> 27.2.4, part "or already had execute permission": had execute
permission for which user category? for the one in question or for any?

>Any category.

>The last sentence in that page says:
>"gives all users permission [...]  if anyone could execute them before".

yes, it says this, but it relates to the example `a+X', where also
_any_one would get executability.
my patch: Add "for anyone" to the sentence "already had execute permission".


>> -explain more fundamentally the relationship between file permission
>> rights and the rights of the corresponding directory , for example
>> regarding to deletion: who has the right to delete file /b/a? users
>> with writing permission on a AND those withrmission on b?

>I think this is a good suggestion (though perhaps not specific to
>coreutils).

Where else would be the place to write about this?

>We recently had a related discussion about that in 'sed',
>where users were surprised that "sed --inplace" can modify a read-only
file.
>https://lists.gnu.org/archive/html/bug-sed/2017-06/msg00000.html

>Similarly on gawk:
>https://lists.gnu.org/archive/html/bug-gawk/2015-06/msg00000.html


>> 27.4: wouldn't it be better to talk about 'operators _in_ numeric
>> mode' rather than from an 'operator numeric mode', since "numeric
>> mode" is an atrribute?

>(I'll leave this to native English speakers)

No native English speakers answering...


>>
>-27.5: it is said, that "a command like `chmod' does not
>> affect the set-user-id, unless […] sets them in a numeric mode".But
>> also, the example states that `chmod 0755' or `mkdir -m 0755'
>> doesn't change set-user/group-id- bits.
>>
>> For me, this doesn't fit together,since the `0' in `0755' explicitly
sets all special mode bits to zero.

>There is some subtlety here, which perhaps can be explained better
(patches are welcomed!).

>Setting (=turning on) sticky/setuid/setgid bits using the 4th octal
digit works as expected (i.e. chmod 4775 DIR).

>In GNU's chmod(1), setting the 4th digit to zero *does not* clear those
bits, it preserves them (i.e. does not change them if they are set).
>To clear them, one needs to specify *five* octal digits: 00755.

>This is explained in the second paragraph of section 27.5:
>"Therefore, a command like chmod does not affect the set-user-ID or
set-group-ID bits of a directory unless the user specifically mentions
them in a symbolic mode, or uses an operator numeric mode such as
‘=755’, or sets them in a numeric mode, or clears them in a numeric mode
that has **five or more** octal digits."
>https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

"does not affect" should be replaced by "does not clear" (because chmod
does affect special mode bits when setting them), "mentions" replaced by
"clears", "or sets them in a numeric mode" has to be taken away (this is
what I wanted to tell by saying that 0755 is an explicit mentioning in
numeric mode -> because this shouldn't  work, numeric mode shouldn't
work for clearing special mode bits).

>The last paragraph on said page also mentions:
>"The GNU behavior with numeric modes of four or fewer digits is
intended for scripts portable to systems that preserve these bits; the
behavior with numeric modes of five or more digits is for scripts
portable to systems that do not preserve the bits."

I don't really understand this paragraph.

>The wording could also be improved in section "27.3 Numeric Modes",
which only mentions this in passing:
>  "However, modes of five digits or more, such as ‘00055’,
>   are sometimes special. See Directory Setuid and Setgid."
>https://www.gnu.org/software/coreutils/manual/html_node/Numeric-Modes.html

My improvement proposal:
Modes of five digits or more, such as `00055', have a special meaning
for directories (see Directory Setuid and Setgid)

The sentence before, "mode `0055' is the same as `55'", is also not very
neat, since it doesn't explain why it is so and if it has something to
do with putting `0' in front when using the language `C'.


>> -27.5,last section, it says: "this behavior is a GNU extension".
Which behavior is meant?

>This refers to the preceding paragraph, dealing with "if you want to
clear these bits".

I propose to replace "This behavior" by "This last behavior" to make it
clearer.


>The behavior differs from other systems (e.g. FreeBSD),
>where "chmod 0775" indeed clears the suid bit.

I think it should also be explained in chapter 27, what the default
permissions are, when creating a file etc.And also: who can change the
permissions, and how?There has to be at least a reference

In the menu 27, there is written about "ANDing" and "ORing".These terms
doesn't appear in the appropriate section, namely 27.4.

>> greetings, kalle

>Thank you for raising these issues.

>If you'd like to suggest better wordings, please do send a patches
>(preferably one patch for each section/topic).

>I'm marking this as "not-a-bug", but keeping it open
>until we either improve these items or decide to keep them as-is.

>regards,
> - assaf

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: improvement proposals texinfo-coreutils,27.3 (numeric modes)
References: <59F78DAE.9070305@HIDDEN>
In-Reply-To: <59F78DAE.9070305@HIDDEN>
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 08 Nov 2017 09:32:02 +0000
Resent-Message-ID: <handler.29069.B29069.151013350922211 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: assafgordon@HIDDEN, 29069 <at> debbugs.gnu.org,  control <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.151013350922211
          (code B ref 29069); Wed, 08 Nov 2017 09:32:02 +0000
Received: (at 29069) by debbugs.gnu.org; 8 Nov 2017 09:31:49 +0000
Received: from localhost ([127.0.0.1]:57572 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eCMi0-0005m3-TA
	for submit <at> debbugs.gnu.org; Wed, 08 Nov 2017 04:31:49 -0500
Received: from mail.netzguerilla.net ([217.11.57.120]:59773)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>)
 id 1eCMhz-0005lR-Ip; Wed, 08 Nov 2017 04:31:44 -0500
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 10CA3100015;
 Wed,  8 Nov 2017 10:31:38 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([IPv6:2a00:1828:2000:612::25])
 by localhost (sal.netzguerilla.net [IPv6:::1]) (amavisd-new, port 10024)
 with ESMTP id qoEt_UPdQS17; Wed,  8 Nov 2017 10:31:36 +0100 (CET)
Received: from [IPv6:2003:dd:fbf2:e201:219:99ff:fe54:3f58]
 (p200300DDFBF2E201021999FFFE543F58.dip0.t-ipconnect.de
 [IPv6:2003:dd:fbf2:e201:219:99ff:fe54:3f58])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id 40937100012;
 Wed,  8 Nov 2017 10:31:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1510133496;
 bh=GfzaFIf+x64BXlS2sI0BFaY6jiUV9YhnRzYGe5QoNAg=;
 h=Date:From:To:Subject:From;
 b=EycCNiNretdZkRlgSbeL5cikUiEUSHf1oLYrI0oPaLFaLTZ6OLPruGYvCM/RCGhDf
 cIjKu7E8EvjsSvSbO5jOl7JwXEdQc8E0OqgNazNVDiThMYA7z8JMP6y3+sSHg9+bHu
 VBXSmbb6a9SCzoLiOFymEi5ranUwiskmhNYyrfXOxqSmE8g3HdZiOw6RgYM659TXhi
 kQEKRGFtd+U+AycGyss53swkt+4MXMKVdC/6++ZzOM+nY9Trit2dg0Sjq/XGsW6ZRB
 GJJtOoOwnvQZ0i7Yc6koK1Nr5A95Iv9wTLrcp6mrB+Z3xuyQ1KMvaPbIQ2wsmxr8ZN
 QW9onPlsMwheQ==
Message-ID: <5A02DCFC.20509@HIDDEN>
Date: Wed, 08 Nov 2017 11:31:24 +0100
From: kalle <kalle@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------010002040709040502070501"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

This is a multi-part message in MIME format.
--------------010002040709040502070501
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

hello there,
this e-mail continues the discussion about improvement proposals about
info coreutils,section "File permissions". '>>' was me
(kalle@HIDDEN writing, '>' was assafgordon@HIDDEN
This mail continues the specialized debate about `27.3 (numeric modes)'.



>> -27.3: is there an info/man-document, where binary,
>> octal, hex-numbers are explained? If, it should be referred to. If
not, shouldn't there be one (and where would it fit in? ) ?-- I
>> could write the text...Since this documentation assumes the knowledge
>> of it..

>Not sure this belongs in the coreutils manual,
>however if you send a patch that would go a long way towards
considering it for inclusion.

I wrote some text,attached to this mail. I think man 7 would be an
appropriate place for this.

>For comparison, I see that "chmod" manual page in OpenBSD, FreeBSD and
>POSIX mention octal code values but do not explain with octal is.
>The reader is expected to either use them as-is, or search for more
details elsewhere.

>https://man.openbsd.org/chmod.1
>https://www.freebsd.org/cgi/man.cgi?query=chmod
>http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

In the introduction of the coreutils-texinfo-document, it says: "many
sections make no attempt to explain basic concepts in a way suitable for
novices. […] get involved in improving this manual"


>  "However, modes of five digits or more, such as ‘00055’,
>   are sometimes special. See Directory Setuid and Setgid."
>https://www.gnu.org/software/coreutils/manual/html_node/Numeric-Modes.html

My improvement proposal:
Modes of five digits or more, such as `00055', have a special meaning
for directories (see Directory Setuid and Setgid)


REMARK: the below section is my improvement proposal of the section
27.3. I left the two first paragraphs unchanged here.The above
transformations are not incorporated yet for your better overview, since
the below part is only a different explanation of the octal model. The
above correction proposals thus still have to be worked in.

27.3 Numeric Modes
==================

As an alternative to giving a symbolic mode, you can give an octal
(base8) number that represents the mode.  This number is always
interpretedin octal; you do not have to add a leading ‘0’, as you do in
C. Mode‘0055’ is the same as mode ‘55’.  (However, modes of five digits
ormore, such as ‘00055’, are sometimes special.  *Note Directory
Setuidand Setgid::.)

A numeric mode is usually shorter than the corresponding symbolicmode,
but it is limited in that normally it cannot take into account
theprevious file mode bits; it can only set them absolutely.
Theset-user-ID and set-group-ID bits of directories are an exception
tothis general limitation.  *Note Directory Setuid and Setgid::.
Also,operator numeric modes can take previous file mode bits into
account.*Note Operator Numeric Modes::.

The octal notation can be derived from the symbolic one,as an
intermediate step transforming it into a binary string (1), which is
then easily changed into octal base (2):

(1)For the intermediate step the `r',`w' and `x'-symbols of the symbolic
notation are changed out at the corresponding place by a `0' or a `1',
according to whether the bits are clear or set  (this works as long as
there are no special mode bits, because every place belongs specifically
to one kind of bit), thus transforming e.g. the string `rwxr-xr--' into
`111101100'.Then instead of overriding the `x'-bits, the special mode
bits are represented by grouping them at the beginning, in the order
suid|guid|sticky/restricted_deletion, thus e.g. describing symbolic
`rwsr-xr-t' as `101111101101'.

(2)Every 3 digits can then be grouped together and described as octal
digits, following the logic that three binary digits `abc' are
translated into an octal number a*2^2+b*2^1+c*2^0=a*4+b*2+c*1, e.g.:

binary	octal
101	5
111	7
011	3

thus transforming the binary `101111101101' from the last example into
octal `5755',

--------------010002040709040502070501
Content-Type: text/plain; charset=UTF-8;
 name="man_number-rep"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="man_number-rep"

QWxsIG5hdHVyYWwgbnVtYmVycyBjYW4gYmUgdW5pcXVlbHkgZGVzY3JpYmVkIHVzaW5nIHRo
ZSBwb3dlcnMgb2YgYSBuYXR1cmFsIG51bWJlciBiIChiXjA9MSxiXjE9YixiXjIsLi4uICks
dGhlIHNvIGNhbGxlZCBiYXNpcywgd2hpY2ggc2hvdWxkIGJlID4xLgpBIG5hdHVyYWwgbnVt
YmVyIG4gY2FuIHRoZW4gYmUgZGVzY3JpYmVkIGJ5IHRoZSBwb3dlcnMgb2YgYiBpbiB0aGUg
Zm9ybQoKbj1hX2sqYl5rK2FfKGstMSkqYl4oay0xKSsuLi4rYV8xKmIrYV8wKjEJCgoJLGkg
ZnJvbSAwIHRvIGsKCSxhX2kgYmVpbmcgbnVtYmVycyBiZXR3ZWVuIDAgYW5kIGItMSwgYmVp
bmcgY2FsbGVkIHRoZSBkaWdpdHMKCSxiXmsgYmVpbmcgdGhlIGJpZ2dlc3QgcG93ZXIgb2Yg
Yiwgd2hpY2ggaXMgc21hbGxlciB0aGFuIG4KCgpJdCBpcyBwcm92YWJsZSwgdGhhdCBnaXZl
biBhIGJhc2lzIGIgdGhlcmUgaXMgZXhhY3RseSBvbmUgc2VxdWVuY2Ugb2YgZGlnaXRzIGFf
ayxhXyhrLTEpLC4uLixhXzEsYV8wJy4gc28gdGhhdCB0aGUgYWJvdmUgZm9ybXVsYSBpcyBj
b3JyZWN0LiBCZWNhdXNlIG9mIHRoaXMsIG9uZSBjYW4gcmVwcmVzZW50IHRoZSBudW1iZXIg
J24nIGJ5IHRoaXMgc2VxdWVuY2Ugb2YgZGlnaXRzICdhX2thXyhrLTEpLi4uYV8xYV8wJy4g
VGhlIGJpZ2dlciAnYicgaXMsIHRoZSBzaG9ydGVyIHRoZSBzZXF1ZW5jZSBhbmQgdmljZSB2
ZXJzYS4KCkZvciBnZW5lcmFsbHkgcmVwcmVzZW50aW5nIG5hdHVyYWwgbnVtYmVycyB0byBi
YXNpcyBiLCBvbmUgdGh1cyBuZWVkcyBiIGRpZmZlcmVudCBzeW1ib2xzIGZvciB0aGUgZGln
aXRzIDAsLi4uLGItMS5DbGFzc2ljYWx5IG9uZSB1c2VzIHRoZSBoaW5kby1hcmFiaWMgZGln
aXRzIDAsMSwyLDMsNCw1LDYsNyw4LDkgYnV0IGZvciBleGFtcGxlIHRvIHRoZSBiYXNlICdz
aXh0ZWVuJyBvbmUgdXNlcyB0aGUgc3ltYm9scyAwLDEsMiwzLDQsNSw2LDcsOCw5LEEsQixD
LEQsRSxGLgoKQXMgYW4gZXhhbXBsZSwgbGV0IHVzIHJlcHJlc2VudCB0aGUgbnVtYmVyICd0
d29odW5kcmVkdGhyZWUnIHRvIHRoZSBiYXNpcyAnZml2ZSc6CjVeMz0xMjUgaXMgdGhlIGJp
Z2dlc3QgcG93ZXIgb2YgZml2ZSBzbWFsbGVyIHRoYW4gJ3R3b2h1bmRyZWR0aHJlZScsZml0
dGluZyBvbmUgdGltZSBpbnRvIG4uIFRodXMgYV8zIGlzIDEuIAo1XjI9MjUgZml0cyAzIHRp
bWVzIGludG8gdGhlIHJlc3QsIGFfMiBiZWluZyA9MywgNV4xPTUgZml0dGluZyB6ZXJvIHRp
bWVzIGluIHRoZSBuZXcgcmVzdCwgYV8xIGJlaW5nID0wLCA1XjA9MSBmaXR0aW5nIDMgdGlt
ZXMgaW50byB0aGUgbGFzdCByZXN0LCBhXzAgYmVpbmcgPTMKVGh1cyB0aGUgcmVwcmVzZW50
YXRpb24gdG8gdGhlIGJhc2lzIDUgIGZvciB0aGUgbnVtYmVyICd0d29odW5kcmVkdGhyZWUn
IGdpdmVzIHVzIDEzMDMuCgpPbiB0aGUgaGFyZHdhcmUgc2NhbGUgb2YgaW5mb3JtYXRpb24g
cHJvY2Vzc2luZywgb25lIHVzdWFsbHkgZGlzdGluZ3Vpc2hlcyBiZXR3ZWVuIHR3byBzdGF0
ZXMsIGFuZCBjb2RlcyBpbmZvcm1hdGlvbiBieSBzZXF1ZW5jZXMgb2YgdGhlc2Ugc3RhdGVz
LCB1c2luZyB0aGUgZGlnaXRzICcwJyBhbmQgJzEnIHRvIHJlcHJlc2VudCB0aGVtLiBUaGUg
c2VxdWVuY2Ugb2YgemVyb3MgYW5kIG9uZXMgY2FuIHRodXMgYmUgaW50ZXJwcmV0ZWQgYXMg
YSBudW1iZXIgdG8gdGhlIGJhc2lzIDIsIGNhbGxlZCBhIGJpbmFyeSBudW1iZXIuClVzdWFs
bHkgdGhpcyByZXByZXNlbnRhdGlvbiBpcyBkZW5zaWZpZWQgd2hlbiBjaGFuZ2luZyB0aGUg
YmFzaXMgaW4gdGhhdCB3YXksIHRoYXQgIGEgZml4ZWQgYW1vdW50IG9mICdiaW5hcnkgZGln
aXRzJyAodXN1YWxseSAzIG9yIDQgb2YgdGhlbSkgY29ycmVzcG9uZCB0byBkaWdpdHMgaW4g
YW5vdGhlciBiYXNpcyAodXN1YWxseSA4IFtvY3RhbF0gYW5kIDE2IFtoZXhhZGVjaW1hbF0p
IGFuZCByZXBsYWNlIHRoZW0gYnkgaXQuSW4gc29tZSBwcm9ncmFtbWluZyBsYW5ndWFnZXMg
YXMgQyB0aGV5IGFyZSBwcmVmaXhlZCBieSBhIGAwJyAob2N0YWwpIG9yIGAweCcgKGhleGFk
ZWNpbWFsKS4KVGh1cyAwMTEwMTExMDAxMDEgKGJpbmFyeSkgYmVjb21lcyAwMzM0NSAob2N0
YWwpIG9yIDB4Q0U5IChoZXhhZGVjaW1hbCkuCgpCZWNhdXNlIDcgYml0cyAoIHNob3J0IGZv
ciAnYmluYXJ5IGRpZ2l0cycpIHdoZXJlIHVzZWQgZm9yIGVhY2ggY2hhcmFjdGVyIGluIHRo
ZSBBU0NJSSAoMSkgY2hhcmFjdGVyIHNldCBhbmQgOCBpbiB0aGUgZXh0ZW5kZWQgZm9ybWF0
cyBzdWNoIGFzIExBVElOLTEsIGl0IGlzIHVzZWZ1bCB0byBpbnRlcnByZXQgOCBiaXRzIChj
YWxsZWQgYSAnYnl0ZScpIGFzIGJhc2ljIGluZm9ybWF0aW9uYWwgdW5pdCwgd2hpY2ggY2Fu
IGJlIGRlc2NyaWJlZCBieSAyIGhleGFkZWNpbWFsIGRpZ2l0cy4K
--------------010002040709040502070501--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: info coreutils file permissions: improvements/bug-report
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 09 Nov 2017 13:14:02 +0000
Resent-Message-ID: <handler.29069.B29069.15102332236661 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: assafgordon@HIDDEN, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.15102332236661
          (code B ref 29069); Thu, 09 Nov 2017 13:14:02 +0000
Received: (at 29069) by debbugs.gnu.org; 9 Nov 2017 13:13:43 +0000
Received: from localhost ([127.0.0.1]:59525 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eCmeN-0001jN-DN
	for submit <at> debbugs.gnu.org; Thu, 09 Nov 2017 08:13:43 -0500
Received: from mail.netzguerilla.net ([217.11.57.120]:60733)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1eCmeK-0001j8-B6
 for 29069 <at> debbugs.gnu.org; Thu, 09 Nov 2017 08:13:40 -0500
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 39F3D100013;
 Thu,  9 Nov 2017 14:13:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([217.11.57.120])
 by localhost (sal.netzguerilla.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9OA3A_E0XYXS; Thu,  9 Nov 2017 14:13:31 +0100 (CET)
Received: from [IPv6:2003:dd:fbf2:e201:226:18ff:fee1:ab1b]
 (p200300DDFBF2E201022618FFFEE1AB1B.dip0.t-ipconnect.de
 [IPv6:2003:dd:fbf2:e201:226:18ff:fee1:ab1b])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id C7FD4100012;
 Thu,  9 Nov 2017 14:13:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1510233211;
 bh=jEaSbYcebJt70h6c9LGiCRQj0fQ9C/+ALxWd58Px+kM=;
 h=Date:From:To:Subject:References:In-Reply-To:From;
 b=pRnecoL2Ii34P7oIXPasXvcG5NuhmtRWYk76/l5vL4pCsJ2wrHjV92lSay6kc80jn
 sJQUkQwEj3srFLs4SuT2H0Yynjvu0+fvgRvb4cY1DlJz6E8gWxvxBsykZikhc1lhUX
 Hc5otOZbxHxdoDcxX7IcZ7smBJ9PxfTtI4yTn4guWGsFUIeZyhrXdTRxLKSkO4DO1S
 DoYLP/fcGPu1XDtY/gd/K7/i0qvjM6Nahema8NuzHYYCebBmULQu/7KP+F8ZsOPxK5
 MVE21eBFIAXHwkPfz8x+sItHQ+ELR7DNDNYjjYb6rovx++d9A/KFCNqpt9NwDoIjpJ
 bpDXm0RZMkt2A==
Message-ID: <5A046277.5030408@HIDDEN>
Date: Thu, 09 Nov 2017 15:13:11 +0100
From: kalle <kalle@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
References: <5A02DCF8.4060200@HIDDEN>
In-Reply-To: <5A02DCF8.4060200@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)


>> There are many good tutorials and guides available in books and online,
>> e.g. https://wiki.debian.org/Permissions .

>It by the way has a wrong description about unsetting special mode bits
> by doing e.g. `chmod '0755'' (see at "Case 4"), which I will correct as
> soon as possible -> more users, less mistakes..

No. Since it is not standard documentation I am a bit exhausted by
discussion about corrections in free software community in difficult
english just now. I would prefer to not correct this mistake now. What
about you?

greetings,
kalle

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: info coreutils file permissions: improvements/bug-report
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 19 Jan 2018 21:26:02 +0000
Resent-Message-ID: <handler.29069.B29069.151639713725556 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: Assaf Gordon <assafgordon@HIDDEN>, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.151639713725556
          (code B ref 29069); Fri, 19 Jan 2018 21:26:02 +0000
Received: (at 29069) by debbugs.gnu.org; 19 Jan 2018 21:25:37 +0000
Received: from localhost ([127.0.0.1]:35315 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eceAL-0006e7-8A
	for submit <at> debbugs.gnu.org; Fri, 19 Jan 2018 16:25:37 -0500
Received: from mail.netzguerilla.net ([217.11.57.120]:56929)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1eceAJ-0006dt-42
 for 29069 <at> debbugs.gnu.org; Fri, 19 Jan 2018 16:25:36 -0500
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id E77D9100024;
 Fri, 19 Jan 2018 22:25:28 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([217.11.57.120])
 by localhost (sal.netzguerilla.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Gt9pffjXkeeU; Fri, 19 Jan 2018 22:25:27 +0100 (CET)
Received: from [IPv6:2003:dd:ff44:b701:f95e:874a:b5b8:aaa0]
 (p200300DDFF44B701F95E874AB5B8AAA0.dip0.t-ipconnect.de
 [IPv6:2003:dd:ff44:b701:f95e:874a:b5b8:aaa0])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id 2CA4B100022;
 Fri, 19 Jan 2018 22:25:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1516397127;
 bh=6rDFRsQqw1j3jUGxgmCq6Cwmjov4igiH6LkY5dtnmJo=;
 h=From:Subject:To:References:Date:In-Reply-To:From;
 b=jDG53zqddwzwYvFJwsXS3xO7NNCTYxGTc25rVd5l2uFXLOijPDdZm7ds0sX/5ygSc
 DqJbR6TuMyPN/+L5loV83YugWafmt53WN4AWNifpZ9A/S5RHjBUlffJ7WA6fId7WCn
 PZM3ZZc9GU++D85sleqqJZM7iD9kR+Vxt3IAoXU+KHCa9CM++z9NGjZ5L85uHIyF+O
 lPhUA7p0QUsYXpuMzkPFuJOptawXNuYWIGGxAR1nrlyTGLI12pasci0ZCT0xFiKtr5
 hiCMq07CnBXVeGkvI/UiNg8Qg17yu9pihh1NJywOHkLed3NQd4Jb4CKxmZEfOJ6+Ve
 fhILwhw0GMoXQ==
From: kalle <kalle@HIDDEN>
References: <59F78DAE.9070305@HIDDEN>
 <30cc4360-5e31-89ef-4840-4e4d5408d14d@HIDDEN>
 <8a2d5c33-724a-23bf-016b-4fb22940ecd8@HIDDEN>
 <bf294d2c-b7e2-ba37-9522-6053dd3bfec3@HIDDEN>
Message-ID: <8987e737-29e5-fdb4-adda-03963d3d8e2f@HIDDEN>
Date: Fri, 19 Jan 2018 22:25:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <bf294d2c-b7e2-ba37-9522-6053dd3bfec3@HIDDEN>
Content-Type: multipart/mixed; boundary="------------879C236DB636989F3BF056D7"
Content-Language: de-DE
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

This is a multi-part message in MIME format.
--------------879C236DB636989F3BF056D7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit



Am 16.12.2017 um 22:14 schrieb Assaf Gordon:
> Hello,
> 
> On 2017-12-16 01:52 PM, kalle wrote:
>> did you plan to respond my mail?
> 
> Please remember GNU coreutils is maintained by volunteers.
> We aim for best effort in incorporating improvement suggestions
> from contributors, but there is no "dead line" for such things.
> 
> You wrote many good suggestions and text improvements.
> 
> If you'd like to see them through, the best way is to
> offer a patch suitable for inclusion.
> For instructions on how to send such patch, please see
>   https://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
>   https://git.savannah.gnu.org/cgit/coreutils.git/tree/README-hacking

I made a patch for chapter 27.3 (Numeric modes) in texinfo coreutils. it
is attached to this mail.
> 
> As your contribution is significant (more than 10 lines),
> it'll also require copyright assignment (see
> https://www.gnu.org/licenses/why-assign.html ).

I hereby assign the copyright on the attached text to the FSF.

Is that enough?

> 
> If you prefer not to spend time on making such a patch, that is of
> course completely fine. In that case, this will have to wait until
> one of the maintainers (or another volunteer) decides to
> spend the time required to incorporate these improvements.
> 
> Also,
> It is best to keep these communications public by sending emails to the
> mailing list, even if it is a simple question of "what's the status?" or
> "any progress?".
> 
> 
> 
> regards,
>  - assaf

greetings,
kalle

--------------879C236DB636989F3BF056D7
Content-Type: text/plain; charset=UTF-8;
 name="patch_numeric_modes"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch_numeric_modes"

RnJvbSBiMjUwZGNkYWJhMDIwODNhMDE3NGQ5MTU3YzY1NWYwZGJiNTg2ZWY2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBrYWxsZSA8a2FsbGVAcHJvamVrdHdlcmtzdGF0dC5k
ZT4KRGF0ZTogV2VkLCAzIEphbiAyMDE4IDIwOjU2OjA3ICswMTAwClN1YmplY3Q6IFtQQVRD
SF0gY2hhbmdlZCBwcmVzZW50YXRpb24gaW4gJ0ZpbGUgcGVybWlzc2lvbnMnIGluICdudW1l
cmljIG1vZGVzJwoKSSBkZXNjcmliZWQgdGhlIG51bWVyaWMgbW9kZXMgZXhwbGFpbmluZyBp
dCdzIG9jdGFsIHJlcHJlc2VudGF0aW9uIGFuZCBob3cgaXQgaXMgb2J0YWluZWQgZnJvbSB0
aGUgc3ltYm9saWMgbm90YXRpb24uCi0tLQogZG9jL3Blcm0udGV4aSB8IDY0ICsrKysrKysr
KysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAx
IGZpbGUgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgNDkgZGVsZXRpb25zKC0pCgpkaWZm
IC0tZ2l0IGEvZG9jL3Blcm0udGV4aSBiL2RvYy9wZXJtLnRleGkKaW5kZXggYzk0YzQ4My4u
YTUxNDk5OCAxMDA2NDQKLS0tIGEvZG9jL3Blcm0udGV4aQorKysgYi9kb2MvcGVybS50ZXhp
CkBAIC00OTEsNTkgKzQ5MSwyNSBAQCB0aGUgZmlsZSB0byBhbGwgdXNlcnMuCiBAY2luZGV4
IG51bWVyaWMgbW9kZXMKIEBjaW5kZXggZmlsZSBtb2RlIGJpdHMsIG51bWVyaWMKIEBjaW5k
ZXggb2N0YWwgbnVtYmVycyBmb3IgZmlsZSBtb2RlcwotQXMgYW4KLWFsdGVybmF0aXZlIHRv
IGdpdmluZyBhIHN5bWJvbGljIG1vZGUsIHlvdSBjYW4gZ2l2ZSBhbiBvY3RhbCAoYmFzZSA4
KQotbnVtYmVyIHRoYXQgcmVwcmVzZW50cyB0aGUgbW9kZS4KLVRoaXMgbnVtYmVyIGlzIGFs
d2F5cyBpbnRlcnByZXRlZCBpbiBvY3RhbDsgeW91IGRvIG5vdCBoYXZlIHRvIGFkZCBhCi1s
ZWFkaW5nIEBzYW1wezB9LCBhcyB5b3UgZG8gaW4gQy4gIE1vZGUgQHNhbXB7MDA1NX0gaXMg
dGhlIHNhbWUgYXMKLW1vZGUgQHNhbXB7NTV9LiAgKEhvd2V2ZXIsIG1vZGVzIG9mIGZpdmUg
ZGlnaXRzIG9yIG1vcmUsIHN1Y2ggYXMKLUBzYW1wezAwMDU1fSwgYXJlIHNvbWV0aW1lcyBz
cGVjaWFsLiAgQHhyZWZ7RGlyZWN0b3J5IFNldHVpZCBhbmQgU2V0Z2lkfS4pCi0KLUEgbnVt
ZXJpYyBtb2RlIGlzIHVzdWFsbHkgc2hvcnRlciB0aGFuIHRoZSBjb3JyZXNwb25kaW5nIHN5
bWJvbGljCi1tb2RlLCBidXQgaXQgaXMgbGltaXRlZCBpbiB0aGF0IG5vcm1hbGx5IGl0IGNh
bm5vdCB0YWtlIGludG8gYWNjb3VudCB0aGUKLXByZXZpb3VzIGZpbGUgbW9kZSBiaXRzOyBp
dCBjYW4gb25seSBzZXQgdGhlbSBhYnNvbHV0ZWx5LgotVGhlIHNldC11c2VyLUlEIGFuZCBz
ZXQtZ3JvdXAtSUQgYml0cyBvZiBkaXJlY3RvcmllcyBhcmUgYW4gZXhjZXB0aW9uCi10byB0
aGlzIGdlbmVyYWwgbGltaXRhdGlvbi4gIEB4cmVme0RpcmVjdG9yeSBTZXR1aWQgYW5kIFNl
dGdpZH0uCi1BbHNvLCBvcGVyYXRvciBudW1lcmljIG1vZGVzIGNhbiB0YWtlIHByZXZpb3Vz
IGZpbGUgbW9kZSBiaXRzIGludG8KLWFjY291bnQuICBAeHJlZntPcGVyYXRvciBOdW1lcmlj
IE1vZGVzfS4KLQotVGhlIHBlcm1pc3Npb25zIGdyYW50ZWQgdG8gdGhlIHVzZXIsCi10byBv
dGhlciB1c2VycyBpbiB0aGUgZmlsZSdzIGdyb3VwLAotYW5kIHRvIG90aGVyIHVzZXJzIG5v
dCBpbiB0aGUgZmlsZSdzIGdyb3VwIGVhY2ggcmVxdWlyZSB0aHJlZQotYml0cywgd2hpY2gg
YXJlIHJlcHJlc2VudGVkIGFzIG9uZSBvY3RhbCBkaWdpdC4gIFRoZSB0aHJlZSBzcGVjaWFs
Ci1tb2RlIGJpdHMgYWxzbyByZXF1aXJlIG9uZSBiaXQgZWFjaCwgYW5kIHRoZXkgYXJlIGFz
IGEgZ3JvdXAKLXJlcHJlc2VudGVkIGFzIGFub3RoZXIgb2N0YWwgZGlnaXQuICBIZXJlIGlz
IGhvdyB0aGUgYml0cyBhcmUgYXJyYW5nZWQsCi1zdGFydGluZyB3aXRoIHRoZSBsb3dlc3Qg
dmFsdWVkIGJpdDoKK0FzIGFuIGFsdGVybmF0aXZlIHRvIGdpdmluZyBhIHN5bWJvbGljIG1v
ZGUsIHlvdSBjYW4gZ2l2ZSBhbiBvY3RhbCAod2l0aCBiYXNlIDgpIG51bWJlciB0aGF0IHJl
cHJlc2VudHMgdGhlIG1vZGUuVGhpcyBudW1iZXIgaXMgYWx3YXlzIGludGVycHJldGVkIGlu
IG9jdGFsOyB5b3UgZG8gbm90IGhhdmUgdG8gYWRkIGEgbGVhZGluZyBAc2FtcHswfSwgYXMg
eW91IGRvIGluIEMuIE1vZGUgQHNhbXB7MDA1NX0gaXMgdGhlIHNhbWUgYXMgbW9kZSBAc2Ft
cHs1NX0uICBNb2RlcyBvZiBmaXZlIGRpZ2l0cyBvciBtb3JlLCBzdWNoIGFzIEBzYW1wezAw
MDU1fSwgaGF2ZSBhIHNwZWNpYWwgbWVhbmluZyBmb3IgZGlyZWN0b3JpZXMgIEB4cmVme0Rp
cmVjdG9yeSBTZXR1aWQgYW5kIFNldGdpZH0uKQorCitBIG51bWVyaWMgbW9kZSBpcyB1c3Vh
bGx5IHNob3J0ZXIgdGhhbiB0aGUgY29ycmVzcG9uZGluZyBzeW1ib2xpYyBtb2RlLCBidXQg
aXQgaXMgbGltaXRlZCBpbiB0aGF0IG5vcm1hbGx5IGl0IGNhbm5vdCB0YWtlIGludG8gYWNj
b3VudCB0aGUgcHJldmlvdXMgZmlsZSBtb2RlIGJpdHM7IGl0IGNhbiBvbmx5IHNldCB0aGVt
IGFic29sdXRlbHkuICBUaGUgc2V0LXVzZXItSUQgYW5kIHNldC1ncm91cC1JRCBiaXRzIG9m
IGRpcmVjdG9yaWVzIGFyZSBhbiBleGNlcHRpb24gdG8gdGhpcyBnZW5lcmFsIGxpbWl0YXRp
b24uICAgQHhyZWZ7RGlyZWN0b3J5IFNldHVpZCBhbmQgU2V0Z2lkfS4gIEFsc28sIG9wZXJh
dG9yIG51bWVyaWMgbW9kZXMgY2FuIHRha2UgcHJldmlvdXMgZmlsZSBtb2RlIGJpdHMgaW50
byBhY2NvdW50LiAgQHhyZWZ7T3BlcmF0b3IgTnVtZXJpYyBNb2Rlc30uCisKK1RoZSBvY3Rh
bCBub3RhdGlvbiBjYW4gYmUgZGVyaXZlZCBmcm9tIHRoZSBzeW1ib2xpYyBvbmUsIGFzIGFu
IGludGVybWVkaWF0ZSBzdGVwIHRyYW5zZm9ybWluZyBpdCBpbnRvIGEgYmluYXJ5IHN0cmlu
ZyAoMSksIHdoaWNoIGlzIHRoZW4gZWFzaWx5IGNoYW5nZWQgaW50byBvY3RhbCBiYXNlICgy
KToKKworKDEpRm9yIHRoZSBpbnRlcm1lZGlhdGUgc3RlcCB0aGUgQHNhbXB7cn0sQHNhbXB7
d30gYW5kIEBzYW1we3h9LXN5bWJvbHMgb2YgdGhlIHN5bWJvbGljIG5vdGF0aW9uIGFyZSBj
aGFuZ2VkIG91dCBhdCB0aGUgY29ycmVzcG9uZGluZyBwbGFjZSBieSBhIEBzYW1wezB9IG9y
IGEgQHNhbXB7MX0sIGFjY29yZGluZyB0byB3aGV0aGVyIHRoZSBiaXRzIGFyZSBjbGVhciBv
ciBzZXQgICh0aGlzIHdvcmtzIGFzIGxvbmcgYXMgdGhlcmUgYXJlIG5vIHNwZWNpYWwgbW9k
ZSBiaXRzLCBiZWNhdXNlIGV2ZXJ5IHBsYWNlIGJlbG9uZ3Mgc3BlY2lmaWNhbGx5IHRvIG9u
ZSBraW5kIG9mIGJpdCksIHRodXMgdHJhbnNmb3JtaW5nIGUuZy4gdGhlIHN0cmluZyBAc2Ft
cHtyd3hyLXhyLS19IGludG8gQHNhbXB7MTExMTAxMTAwfS5UaGVuIGluc3RlYWQgb2Ygb3Zl
cnJpZGluZyB0aGUgQHNhbXB7eH0tYml0cywgdGhlIHNwZWNpYWwgbW9kZSBiaXRzIGFyZSBy
ZXByZXNlbnRlZCBieSBncm91cGluZyB0aGVtIGF0IHRoZSBiZWdpbm5pbmcsIGluIHRoZSBv
cmRlciBzdWlkfGd1aWR8c3RpY2t5L3Jlc3RyaWN0ZWRfZGVsZXRpb24sIHRodXMgZS5nLiBk
ZXNjcmliaW5nIHN5bWJvbGljIEBzYW1we3J3c3IteHItdH0gYXMgQHNhbXB7MTAxMTExMTAx
MTAxfS4gCisKKygyKUV2ZXJ5IDMgZGlnaXRzIGNhbiB0aGVuIGJlIGdyb3VwZWQgdG9nZXRo
ZXIgYW5kIGRlc2NyaWJlZCBhcyBhbiBvY3RhbCBkaWdpdCwgZm9sbG93aW5nIHRoZSBsb2dp
YyB0aGF0IHRocmVlIGJpbmFyeSBkaWdpdHMgQHNhbXB7YWJjfSBhcmUgdHJhbnNsYXRlZCBp
bnRvIGFuIG9jdGFsIG51bWJlciBhKjJeMitiKjJeMStjKjJeMD1hKjQrYioyK2MqMSwgZS5n
LjoKIAogQGV4YW1wbGUKLVZhbHVlIGluICBDb3JyZXNwb25kaW5nCi1Nb2RlICAgICAgTW9k
ZSBCaXQKLQotICAgICAgICAgIE90aGVyIHVzZXJzIG5vdCBpbiB0aGUgZmlsZSdzIGdyb3Vw
OgotICAgMSAgICAgIEV4ZWN1dGUvc2VhcmNoCi0gICAyICAgICAgV3JpdGUKLSAgIDQgICAg
ICBSZWFkCi0KLSAgICAgICAgICBPdGhlciB1c2VycyBpbiB0aGUgZmlsZSdzIGdyb3VwOgot
ICAxMCAgICAgIEV4ZWN1dGUvc2VhcmNoCi0gIDIwICAgICAgV3JpdGUKLSAgNDAgICAgICBS
ZWFkCi0KLSAgICAgICAgICBUaGUgZmlsZSdzIG93bmVyOgotIDEwMCAgICAgIEV4ZWN1dGUv
c2VhcmNoCi0gMjAwICAgICAgV3JpdGUKLSA0MDAgICAgICBSZWFkCi0KLSAgICAgICAgICBT
cGVjaWFsIG1vZGUgYml0czoKLTEwMDAgICAgICBSZXN0cmljdGVkIGRlbGV0aW9uIGZsYWcg
b3Igc3RpY2t5IGJpdAotMjAwMCAgICAgIFNldCBncm91cCBJRCBvbiBleGVjdXRpb24KLTQw
MDAgICAgICBTZXQgdXNlciBJRCBvbiBleGVjdXRpb24KK2JpbmFyeQlvY3RhbAorMTAxCTUK
KzExMQk3CiswMTEJMwogQGVuZCBleGFtcGxlCiAKLUZvciBleGFtcGxlLCBudW1lcmljIG1v
ZGUgQHNhbXB7NDc1NX0gY29ycmVzcG9uZHMgdG8gc3ltYm9saWMgbW9kZQotQHNhbXB7dT1y
d3hzLGdvPXJ4fSwgYW5kIG51bWVyaWMgbW9kZSBAc2FtcHs2NjR9IGNvcnJlc3BvbmRzIHRv
IHN5bWJvbGljIG1vZGUKLUBzYW1we3VnPXJ3LG89cn0uICBOdW1lcmljIG1vZGUgQHNhbXB7
MH0gY29ycmVzcG9uZHMgdG8gc3ltYm9saWMgbW9kZQotQHNhbXB7YT19LgordGh1cyB0cmFu
c2Zvcm1pbmcgdGhlIGJpbmFyeSBAc2FtcHsxMDExMTExMDExMDF9IGZyb20gdGhlIGxhc3Qg
ZXhhbXBsZSBpbnRvIG9jdGFsIEBzYW1wezU3NTV9LgorCiAKIEBub2RlIE9wZXJhdG9yIE51
bWVyaWMgTW9kZXMKIEBzZWN0aW9uIE9wZXJhdG9yIE51bWVyaWMgTW9kZXMKLS0gCjEuOS4x
Cgo=
--------------879C236DB636989F3BF056D7--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: Fwd: Re: bug#29069: info coreutils file permissions: improvements/bug-report
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 31 Jan 2018 00:35:01 +0000
Resent-Message-ID: <handler.29069.B.15173588968283 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: 29069 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-coreutils@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.15173588968283
          (code B ref -1); Wed, 31 Jan 2018 00:35:01 +0000
Received: (at submit) by debbugs.gnu.org; 31 Jan 2018 00:34:56 +0000
Received: from localhost ([127.0.0.1]:49993 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eggMZ-00029V-M6
	for submit <at> debbugs.gnu.org; Tue, 30 Jan 2018 19:34:55 -0500
Received: from eggs.gnu.org ([208.118.235.92]:33963)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1eggMY-00029K-B9
 for submit <at> debbugs.gnu.org; Tue, 30 Jan 2018 19:34:54 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1eggMR-00081T-UW
 for submit <at> debbugs.gnu.org; Tue, 30 Jan 2018 19:34:49 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:35911)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <kalle@HIDDEN>)
 id 1eggMR-00081D-QZ
 for submit <at> debbugs.gnu.org; Tue, 30 Jan 2018 19:34:47 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53095)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1eggMQ-0005Tb-B5
 for bug-coreutils@HIDDEN; Tue, 30 Jan 2018 19:34:47 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1eggMJ-0007sC-4L
 for bug-coreutils@HIDDEN; Tue, 30 Jan 2018 19:34:46 -0500
Received: from mail.netzguerilla.net ([217.11.57.120]:59939)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <kalle@HIDDEN>)
 id 1eggMI-0007oE-C1
 for bug-coreutils@HIDDEN; Tue, 30 Jan 2018 19:34:38 -0500
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 114E510001B
 for <bug-coreutils@HIDDEN>; Wed, 31 Jan 2018 00:55:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([217.11.57.120])
 by localhost (sal.netzguerilla.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id PqWSQVCgjQGp for <bug-coreutils@HIDDEN>;
 Wed, 31 Jan 2018 00:55:46 +0100 (CET)
Received: from [IPv6:2003:dd:ff35:2201:3534:81ac:bb0:225b]
 (p200300DDFF352201353481AC0BB0225B.dip0.t-ipconnect.de
 [IPv6:2003:dd:ff35:2201:3534:81ac:bb0:225b])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id 64525100019
 for <bug-coreutils@HIDDEN>; Wed, 31 Jan 2018 00:55:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1517356546;
 bh=gzhIJDgQsGRqQmLjBNfFhGvYOjvjYmGvkima+jultAE=;
 h=Subject:References:To:From:Date:In-Reply-To:From;
 b=CQc/x597NzCfJaRHzkfrwBBhswaa56Ti8yaF1IhooPUudJkZZPPaqaLj7vAUCiqeg
 GJP0bbG7RRfMXChexiWGwx0pYgvLBCXNYn8tFGKz5nUgmG/YN3CrafZGMkeSKYIqUD
 VMW8VuatYctlySIpesbIPzyqqjtl72RbarEN0J1wPZ8KZip9bkM0Ykz+BPt1z2lduW
 iLc668hvRdfbwfhQ/n/knABPrQMCb6GKbNMSgNXB8hebrC7XNKt/2N0p3Fbi1/K0rw
 JV87kT/hE6A07AcX2lR2VEzUNVm52fcgKITFZttMH2G1XpaawDffkwl8u0XUAAPv4U
 0kWhlKlMHJhnQ==
References: <8987e737-29e5-fdb4-adda-03963d3d8e2f@HIDDEN>
From: kalle <kalle@HIDDEN>
X-Forwarded-Message-Id: <8987e737-29e5-fdb4-adda-03963d3d8e2f@HIDDEN>
Message-ID: <97da4c35-1b8b-9f11-ab72-d4035f514162@HIDDEN>
Date: Wed, 31 Jan 2018 00:55:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101
 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <8987e737-29e5-fdb4-adda-03963d3d8e2f@HIDDEN>
Content-Type: multipart/mixed; boundary="------------D648C4C56B8F3956A466EB8A"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
 [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is a multi-part message in MIME format.
--------------D648C4C56B8F3956A466EB8A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I have a patch for chapter 27.3, coreutils texinfo-document.

greetings,
kalle

--------------D648C4C56B8F3956A466EB8A
Content-Type: text/plain; charset=UTF-8;
 name="patch_numeric_modes"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch_numeric_modes"

RnJvbSBiMjUwZGNkYWJhMDIwODNhMDE3NGQ5MTU3YzY1NWYwZGJiNTg2ZWY2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBrYWxsZSA8a2FsbGVAcHJvamVrdHdlcmtzdGF0dC5k
ZT4KRGF0ZTogV2VkLCAzIEphbiAyMDE4IDIwOjU2OjA3ICswMTAwClN1YmplY3Q6IFtQQVRD
SF0gY2hhbmdlZCBwcmVzZW50YXRpb24gaW4gJ0ZpbGUgcGVybWlzc2lvbnMnIGluICdudW1l
cmljIG1vZGVzJwoKSSBkZXNjcmliZWQgdGhlIG51bWVyaWMgbW9kZXMgZXhwbGFpbmluZyBp
dCdzIG9jdGFsIHJlcHJlc2VudGF0aW9uIGFuZCBob3cgaXQgaXMgb2J0YWluZWQgZnJvbSB0
aGUgc3ltYm9saWMgbm90YXRpb24uCi0tLQogZG9jL3Blcm0udGV4aSB8IDY0ICsrKysrKysr
KysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAx
IGZpbGUgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgNDkgZGVsZXRpb25zKC0pCgpkaWZm
IC0tZ2l0IGEvZG9jL3Blcm0udGV4aSBiL2RvYy9wZXJtLnRleGkKaW5kZXggYzk0YzQ4My4u
YTUxNDk5OCAxMDA2NDQKLS0tIGEvZG9jL3Blcm0udGV4aQorKysgYi9kb2MvcGVybS50ZXhp
CkBAIC00OTEsNTkgKzQ5MSwyNSBAQCB0aGUgZmlsZSB0byBhbGwgdXNlcnMuCiBAY2luZGV4
IG51bWVyaWMgbW9kZXMKIEBjaW5kZXggZmlsZSBtb2RlIGJpdHMsIG51bWVyaWMKIEBjaW5k
ZXggb2N0YWwgbnVtYmVycyBmb3IgZmlsZSBtb2RlcwotQXMgYW4KLWFsdGVybmF0aXZlIHRv
IGdpdmluZyBhIHN5bWJvbGljIG1vZGUsIHlvdSBjYW4gZ2l2ZSBhbiBvY3RhbCAoYmFzZSA4
KQotbnVtYmVyIHRoYXQgcmVwcmVzZW50cyB0aGUgbW9kZS4KLVRoaXMgbnVtYmVyIGlzIGFs
d2F5cyBpbnRlcnByZXRlZCBpbiBvY3RhbDsgeW91IGRvIG5vdCBoYXZlIHRvIGFkZCBhCi1s
ZWFkaW5nIEBzYW1wezB9LCBhcyB5b3UgZG8gaW4gQy4gIE1vZGUgQHNhbXB7MDA1NX0gaXMg
dGhlIHNhbWUgYXMKLW1vZGUgQHNhbXB7NTV9LiAgKEhvd2V2ZXIsIG1vZGVzIG9mIGZpdmUg
ZGlnaXRzIG9yIG1vcmUsIHN1Y2ggYXMKLUBzYW1wezAwMDU1fSwgYXJlIHNvbWV0aW1lcyBz
cGVjaWFsLiAgQHhyZWZ7RGlyZWN0b3J5IFNldHVpZCBhbmQgU2V0Z2lkfS4pCi0KLUEgbnVt
ZXJpYyBtb2RlIGlzIHVzdWFsbHkgc2hvcnRlciB0aGFuIHRoZSBjb3JyZXNwb25kaW5nIHN5
bWJvbGljCi1tb2RlLCBidXQgaXQgaXMgbGltaXRlZCBpbiB0aGF0IG5vcm1hbGx5IGl0IGNh
bm5vdCB0YWtlIGludG8gYWNjb3VudCB0aGUKLXByZXZpb3VzIGZpbGUgbW9kZSBiaXRzOyBp
dCBjYW4gb25seSBzZXQgdGhlbSBhYnNvbHV0ZWx5LgotVGhlIHNldC11c2VyLUlEIGFuZCBz
ZXQtZ3JvdXAtSUQgYml0cyBvZiBkaXJlY3RvcmllcyBhcmUgYW4gZXhjZXB0aW9uCi10byB0
aGlzIGdlbmVyYWwgbGltaXRhdGlvbi4gIEB4cmVme0RpcmVjdG9yeSBTZXR1aWQgYW5kIFNl
dGdpZH0uCi1BbHNvLCBvcGVyYXRvciBudW1lcmljIG1vZGVzIGNhbiB0YWtlIHByZXZpb3Vz
IGZpbGUgbW9kZSBiaXRzIGludG8KLWFjY291bnQuICBAeHJlZntPcGVyYXRvciBOdW1lcmlj
IE1vZGVzfS4KLQotVGhlIHBlcm1pc3Npb25zIGdyYW50ZWQgdG8gdGhlIHVzZXIsCi10byBv
dGhlciB1c2VycyBpbiB0aGUgZmlsZSdzIGdyb3VwLAotYW5kIHRvIG90aGVyIHVzZXJzIG5v
dCBpbiB0aGUgZmlsZSdzIGdyb3VwIGVhY2ggcmVxdWlyZSB0aHJlZQotYml0cywgd2hpY2gg
YXJlIHJlcHJlc2VudGVkIGFzIG9uZSBvY3RhbCBkaWdpdC4gIFRoZSB0aHJlZSBzcGVjaWFs
Ci1tb2RlIGJpdHMgYWxzbyByZXF1aXJlIG9uZSBiaXQgZWFjaCwgYW5kIHRoZXkgYXJlIGFz
IGEgZ3JvdXAKLXJlcHJlc2VudGVkIGFzIGFub3RoZXIgb2N0YWwgZGlnaXQuICBIZXJlIGlz
IGhvdyB0aGUgYml0cyBhcmUgYXJyYW5nZWQsCi1zdGFydGluZyB3aXRoIHRoZSBsb3dlc3Qg
dmFsdWVkIGJpdDoKK0FzIGFuIGFsdGVybmF0aXZlIHRvIGdpdmluZyBhIHN5bWJvbGljIG1v
ZGUsIHlvdSBjYW4gZ2l2ZSBhbiBvY3RhbCAod2l0aCBiYXNlIDgpIG51bWJlciB0aGF0IHJl
cHJlc2VudHMgdGhlIG1vZGUuVGhpcyBudW1iZXIgaXMgYWx3YXlzIGludGVycHJldGVkIGlu
IG9jdGFsOyB5b3UgZG8gbm90IGhhdmUgdG8gYWRkIGEgbGVhZGluZyBAc2FtcHswfSwgYXMg
eW91IGRvIGluIEMuIE1vZGUgQHNhbXB7MDA1NX0gaXMgdGhlIHNhbWUgYXMgbW9kZSBAc2Ft
cHs1NX0uICBNb2RlcyBvZiBmaXZlIGRpZ2l0cyBvciBtb3JlLCBzdWNoIGFzIEBzYW1wezAw
MDU1fSwgaGF2ZSBhIHNwZWNpYWwgbWVhbmluZyBmb3IgZGlyZWN0b3JpZXMgIEB4cmVme0Rp
cmVjdG9yeSBTZXR1aWQgYW5kIFNldGdpZH0uKQorCitBIG51bWVyaWMgbW9kZSBpcyB1c3Vh
bGx5IHNob3J0ZXIgdGhhbiB0aGUgY29ycmVzcG9uZGluZyBzeW1ib2xpYyBtb2RlLCBidXQg
aXQgaXMgbGltaXRlZCBpbiB0aGF0IG5vcm1hbGx5IGl0IGNhbm5vdCB0YWtlIGludG8gYWNj
b3VudCB0aGUgcHJldmlvdXMgZmlsZSBtb2RlIGJpdHM7IGl0IGNhbiBvbmx5IHNldCB0aGVt
IGFic29sdXRlbHkuICBUaGUgc2V0LXVzZXItSUQgYW5kIHNldC1ncm91cC1JRCBiaXRzIG9m
IGRpcmVjdG9yaWVzIGFyZSBhbiBleGNlcHRpb24gdG8gdGhpcyBnZW5lcmFsIGxpbWl0YXRp
b24uICAgQHhyZWZ7RGlyZWN0b3J5IFNldHVpZCBhbmQgU2V0Z2lkfS4gIEFsc28sIG9wZXJh
dG9yIG51bWVyaWMgbW9kZXMgY2FuIHRha2UgcHJldmlvdXMgZmlsZSBtb2RlIGJpdHMgaW50
byBhY2NvdW50LiAgQHhyZWZ7T3BlcmF0b3IgTnVtZXJpYyBNb2Rlc30uCisKK1RoZSBvY3Rh
bCBub3RhdGlvbiBjYW4gYmUgZGVyaXZlZCBmcm9tIHRoZSBzeW1ib2xpYyBvbmUsIGFzIGFu
IGludGVybWVkaWF0ZSBzdGVwIHRyYW5zZm9ybWluZyBpdCBpbnRvIGEgYmluYXJ5IHN0cmlu
ZyAoMSksIHdoaWNoIGlzIHRoZW4gZWFzaWx5IGNoYW5nZWQgaW50byBvY3RhbCBiYXNlICgy
KToKKworKDEpRm9yIHRoZSBpbnRlcm1lZGlhdGUgc3RlcCB0aGUgQHNhbXB7cn0sQHNhbXB7
d30gYW5kIEBzYW1we3h9LXN5bWJvbHMgb2YgdGhlIHN5bWJvbGljIG5vdGF0aW9uIGFyZSBj
aGFuZ2VkIG91dCBhdCB0aGUgY29ycmVzcG9uZGluZyBwbGFjZSBieSBhIEBzYW1wezB9IG9y
IGEgQHNhbXB7MX0sIGFjY29yZGluZyB0byB3aGV0aGVyIHRoZSBiaXRzIGFyZSBjbGVhciBv
ciBzZXQgICh0aGlzIHdvcmtzIGFzIGxvbmcgYXMgdGhlcmUgYXJlIG5vIHNwZWNpYWwgbW9k
ZSBiaXRzLCBiZWNhdXNlIGV2ZXJ5IHBsYWNlIGJlbG9uZ3Mgc3BlY2lmaWNhbGx5IHRvIG9u
ZSBraW5kIG9mIGJpdCksIHRodXMgdHJhbnNmb3JtaW5nIGUuZy4gdGhlIHN0cmluZyBAc2Ft
cHtyd3hyLXhyLS19IGludG8gQHNhbXB7MTExMTAxMTAwfS5UaGVuIGluc3RlYWQgb2Ygb3Zl
cnJpZGluZyB0aGUgQHNhbXB7eH0tYml0cywgdGhlIHNwZWNpYWwgbW9kZSBiaXRzIGFyZSBy
ZXByZXNlbnRlZCBieSBncm91cGluZyB0aGVtIGF0IHRoZSBiZWdpbm5pbmcsIGluIHRoZSBv
cmRlciBzdWlkfGd1aWR8c3RpY2t5L3Jlc3RyaWN0ZWRfZGVsZXRpb24sIHRodXMgZS5nLiBk
ZXNjcmliaW5nIHN5bWJvbGljIEBzYW1we3J3c3IteHItdH0gYXMgQHNhbXB7MTAxMTExMTAx
MTAxfS4gCisKKygyKUV2ZXJ5IDMgZGlnaXRzIGNhbiB0aGVuIGJlIGdyb3VwZWQgdG9nZXRo
ZXIgYW5kIGRlc2NyaWJlZCBhcyBhbiBvY3RhbCBkaWdpdCwgZm9sbG93aW5nIHRoZSBsb2dp
YyB0aGF0IHRocmVlIGJpbmFyeSBkaWdpdHMgQHNhbXB7YWJjfSBhcmUgdHJhbnNsYXRlZCBp
bnRvIGFuIG9jdGFsIG51bWJlciBhKjJeMitiKjJeMStjKjJeMD1hKjQrYioyK2MqMSwgZS5n
LjoKIAogQGV4YW1wbGUKLVZhbHVlIGluICBDb3JyZXNwb25kaW5nCi1Nb2RlICAgICAgTW9k
ZSBCaXQKLQotICAgICAgICAgIE90aGVyIHVzZXJzIG5vdCBpbiB0aGUgZmlsZSdzIGdyb3Vw
OgotICAgMSAgICAgIEV4ZWN1dGUvc2VhcmNoCi0gICAyICAgICAgV3JpdGUKLSAgIDQgICAg
ICBSZWFkCi0KLSAgICAgICAgICBPdGhlciB1c2VycyBpbiB0aGUgZmlsZSdzIGdyb3VwOgot
ICAxMCAgICAgIEV4ZWN1dGUvc2VhcmNoCi0gIDIwICAgICAgV3JpdGUKLSAgNDAgICAgICBS
ZWFkCi0KLSAgICAgICAgICBUaGUgZmlsZSdzIG93bmVyOgotIDEwMCAgICAgIEV4ZWN1dGUv
c2VhcmNoCi0gMjAwICAgICAgV3JpdGUKLSA0MDAgICAgICBSZWFkCi0KLSAgICAgICAgICBT
cGVjaWFsIG1vZGUgYml0czoKLTEwMDAgICAgICBSZXN0cmljdGVkIGRlbGV0aW9uIGZsYWcg
b3Igc3RpY2t5IGJpdAotMjAwMCAgICAgIFNldCBncm91cCBJRCBvbiBleGVjdXRpb24KLTQw
MDAgICAgICBTZXQgdXNlciBJRCBvbiBleGVjdXRpb24KK2JpbmFyeQlvY3RhbAorMTAxCTUK
KzExMQk3CiswMTEJMwogQGVuZCBleGFtcGxlCiAKLUZvciBleGFtcGxlLCBudW1lcmljIG1v
ZGUgQHNhbXB7NDc1NX0gY29ycmVzcG9uZHMgdG8gc3ltYm9saWMgbW9kZQotQHNhbXB7dT1y
d3hzLGdvPXJ4fSwgYW5kIG51bWVyaWMgbW9kZSBAc2FtcHs2NjR9IGNvcnJlc3BvbmRzIHRv
IHN5bWJvbGljIG1vZGUKLUBzYW1we3VnPXJ3LG89cn0uICBOdW1lcmljIG1vZGUgQHNhbXB7
MH0gY29ycmVzcG9uZHMgdG8gc3ltYm9saWMgbW9kZQotQHNhbXB7YT19LgordGh1cyB0cmFu
c2Zvcm1pbmcgdGhlIGJpbmFyeSBAc2FtcHsxMDExMTExMDExMDF9IGZyb20gdGhlIGxhc3Qg
ZXhhbXBsZSBpbnRvIG9jdGFsIEBzYW1wezU3NTV9LgorCiAKIEBub2RlIE9wZXJhdG9yIE51
bWVyaWMgTW9kZXMKIEBzZWN0aW9uIE9wZXJhdG9yIE51bWVyaWMgTW9kZXMKLS0gCjEuOS4x
Cgo=
--------------D648C4C56B8F3956A466EB8A--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: Fwd: Fwd: Re: bug#29069: info coreutils file permissions: improvements/bug-report
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 12 Mar 2018 23:26:01 +0000
Resent-Message-ID: <handler.29069.B.152089712428185 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: 29069 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-coreutils@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.152089712428185
          (code B ref -1); Mon, 12 Mar 2018 23:26:01 +0000
Received: (at submit) by debbugs.gnu.org; 12 Mar 2018 23:25:24 +0000
Received: from localhost ([127.0.0.1]:57821 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1evWok-0007KU-Oa
	for submit <at> debbugs.gnu.org; Mon, 12 Mar 2018 19:25:23 -0400
Received: from eggs.gnu.org ([208.118.235.92]:57144)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1evWoi-0007KH-PU
 for submit <at> debbugs.gnu.org; Mon, 12 Mar 2018 19:25:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1evWoc-00015N-8G
 for submit <at> debbugs.gnu.org; Mon, 12 Mar 2018 19:25:15 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:33655)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <kalle@HIDDEN>)
 id 1evWob-000156-Uo
 for submit <at> debbugs.gnu.org; Mon, 12 Mar 2018 19:25:14 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48098)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1evWoa-0005QL-Cr
 for bug-coreutils@HIDDEN; Mon, 12 Mar 2018 19:25:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1evWoX-000100-4W
 for bug-coreutils@HIDDEN; Mon, 12 Mar 2018 19:25:12 -0400
Received: from mail.netzguerilla.net ([2a00:1828:2000:612::25]:58919)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <kalle@HIDDEN>)
 id 1evWoW-0000u3-Mp
 for bug-coreutils@HIDDEN; Mon, 12 Mar 2018 19:25:09 -0400
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 8887B100017
 for <bug-coreutils@HIDDEN>; Tue, 13 Mar 2018 00:25:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([217.11.57.120])
 by localhost (sal.netzguerilla.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id z4h8mA5gWoqR for <bug-coreutils@HIDDEN>;
 Tue, 13 Mar 2018 00:24:59 +0100 (CET)
Received: from [IPv6:2003:dd:ff29:a301:1576:caa5:f498:b662]
 (p200300DDFF29A3011576CAA5F498B662.dip0.t-ipconnect.de
 [IPv6:2003:dd:ff29:a301:1576:caa5:f498:b662])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id 10AE7100012
 for <bug-coreutils@HIDDEN>; Tue, 13 Mar 2018 00:24:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1520897099;
 bh=iAbUE6Jh/eheg5Eyxco9yF0PeXW5Ar5WOSizy8g3/z4=;
 h=Subject:References:To:From:Date:In-Reply-To:From;
 b=HD76EkT3wSzWQHxD1ICt8v18fx9Cl5Vvy67nreibXYXHie6OjwUsqMxkE4Hes9Rsi
 K+sbFevSKwLFU+dGQJheAYh1gCp8WlaltqOHKLIATqhETJldd5Aj2LJ3Nhc63hQOvd
 zeXZRDxclQ3FDelQUXaYbiQq8FEhk01L+SQ8uVvfwIUThOVkLbtm/w3Od9BUou0kZs
 StXTJuv5Krb/NCFFuRvKx38N56UXJ3n2FuhdjP0H0FiUnmhl9ohxDBvv6NlK2luPiV
 Jj+iR7gTZZ/1AghUg1xw0M8GU2IGqKxD2T4Acu9ugULwz4oLIjj/eDHT3PqomClyjR
 RzUcaxS4Tn68g==
References: <97da4c35-1b8b-9f11-ab72-d4035f514162@HIDDEN>
From: kalle <kalle@HIDDEN>
X-Forwarded-Message-Id: <97da4c35-1b8b-9f11-ab72-d4035f514162@HIDDEN>
Message-ID: <54b054f4-f07e-d70d-0834-a5ac3e288c21@HIDDEN>
Date: Tue, 13 Mar 2018 00:24:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <97da4c35-1b8b-9f11-ab72-d4035f514162@HIDDEN>
Content-Type: multipart/mixed; boundary="------------574FB62A092744D601952522"
Content-Language: de-DE
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is a multi-part message in MIME format.
--------------574FB62A092744D601952522
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

until now, no one responded to my patch proposal neither  encorporated
it as I see.
why not?
kalle


-------- Weitergeleitete Nachricht --------
Betreff: Fwd: Re: bug#29069: info coreutils file permissions:
improvements/bug-report
Datum: Wed, 31 Jan 2018 00:55:31 +0100
Von: kalle <kalle@HIDDEN>
An: bug-coreutils@HIDDEN

I have a patch for chapter 27.3, coreutils texinfo-document.

greetings,
kalle


--------------574FB62A092744D601952522
Content-Type: text/plain; charset=UTF-8;
 name="patch_numeric_modes"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch_numeric_modes"

RnJvbSBiMjUwZGNkYWJhMDIwODNhMDE3NGQ5MTU3YzY1NWYwZGJiNTg2ZWY2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBrYWxsZSA8a2FsbGVAcHJvamVrdHdlcmtzdGF0dC5k
ZT4KRGF0ZTogV2VkLCAzIEphbiAyMDE4IDIwOjU2OjA3ICswMTAwClN1YmplY3Q6IFtQQVRD
SF0gY2hhbmdlZCBwcmVzZW50YXRpb24gaW4gJ0ZpbGUgcGVybWlzc2lvbnMnIGluICdudW1l
cmljIG1vZGVzJwoKSSBkZXNjcmliZWQgdGhlIG51bWVyaWMgbW9kZXMgZXhwbGFpbmluZyBp
dCdzIG9jdGFsIHJlcHJlc2VudGF0aW9uIGFuZCBob3cgaXQgaXMgb2J0YWluZWQgZnJvbSB0
aGUgc3ltYm9saWMgbm90YXRpb24uCi0tLQogZG9jL3Blcm0udGV4aSB8IDY0ICsrKysrKysr
KysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAx
IGZpbGUgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgNDkgZGVsZXRpb25zKC0pCgpkaWZm
IC0tZ2l0IGEvZG9jL3Blcm0udGV4aSBiL2RvYy9wZXJtLnRleGkKaW5kZXggYzk0YzQ4My4u
YTUxNDk5OCAxMDA2NDQKLS0tIGEvZG9jL3Blcm0udGV4aQorKysgYi9kb2MvcGVybS50ZXhp
CkBAIC00OTEsNTkgKzQ5MSwyNSBAQCB0aGUgZmlsZSB0byBhbGwgdXNlcnMuCiBAY2luZGV4
IG51bWVyaWMgbW9kZXMKIEBjaW5kZXggZmlsZSBtb2RlIGJpdHMsIG51bWVyaWMKIEBjaW5k
ZXggb2N0YWwgbnVtYmVycyBmb3IgZmlsZSBtb2RlcwotQXMgYW4KLWFsdGVybmF0aXZlIHRv
IGdpdmluZyBhIHN5bWJvbGljIG1vZGUsIHlvdSBjYW4gZ2l2ZSBhbiBvY3RhbCAoYmFzZSA4
KQotbnVtYmVyIHRoYXQgcmVwcmVzZW50cyB0aGUgbW9kZS4KLVRoaXMgbnVtYmVyIGlzIGFs
d2F5cyBpbnRlcnByZXRlZCBpbiBvY3RhbDsgeW91IGRvIG5vdCBoYXZlIHRvIGFkZCBhCi1s
ZWFkaW5nIEBzYW1wezB9LCBhcyB5b3UgZG8gaW4gQy4gIE1vZGUgQHNhbXB7MDA1NX0gaXMg
dGhlIHNhbWUgYXMKLW1vZGUgQHNhbXB7NTV9LiAgKEhvd2V2ZXIsIG1vZGVzIG9mIGZpdmUg
ZGlnaXRzIG9yIG1vcmUsIHN1Y2ggYXMKLUBzYW1wezAwMDU1fSwgYXJlIHNvbWV0aW1lcyBz
cGVjaWFsLiAgQHhyZWZ7RGlyZWN0b3J5IFNldHVpZCBhbmQgU2V0Z2lkfS4pCi0KLUEgbnVt
ZXJpYyBtb2RlIGlzIHVzdWFsbHkgc2hvcnRlciB0aGFuIHRoZSBjb3JyZXNwb25kaW5nIHN5
bWJvbGljCi1tb2RlLCBidXQgaXQgaXMgbGltaXRlZCBpbiB0aGF0IG5vcm1hbGx5IGl0IGNh
bm5vdCB0YWtlIGludG8gYWNjb3VudCB0aGUKLXByZXZpb3VzIGZpbGUgbW9kZSBiaXRzOyBp
dCBjYW4gb25seSBzZXQgdGhlbSBhYnNvbHV0ZWx5LgotVGhlIHNldC11c2VyLUlEIGFuZCBz
ZXQtZ3JvdXAtSUQgYml0cyBvZiBkaXJlY3RvcmllcyBhcmUgYW4gZXhjZXB0aW9uCi10byB0
aGlzIGdlbmVyYWwgbGltaXRhdGlvbi4gIEB4cmVme0RpcmVjdG9yeSBTZXR1aWQgYW5kIFNl
dGdpZH0uCi1BbHNvLCBvcGVyYXRvciBudW1lcmljIG1vZGVzIGNhbiB0YWtlIHByZXZpb3Vz
IGZpbGUgbW9kZSBiaXRzIGludG8KLWFjY291bnQuICBAeHJlZntPcGVyYXRvciBOdW1lcmlj
IE1vZGVzfS4KLQotVGhlIHBlcm1pc3Npb25zIGdyYW50ZWQgdG8gdGhlIHVzZXIsCi10byBv
dGhlciB1c2VycyBpbiB0aGUgZmlsZSdzIGdyb3VwLAotYW5kIHRvIG90aGVyIHVzZXJzIG5v
dCBpbiB0aGUgZmlsZSdzIGdyb3VwIGVhY2ggcmVxdWlyZSB0aHJlZQotYml0cywgd2hpY2gg
YXJlIHJlcHJlc2VudGVkIGFzIG9uZSBvY3RhbCBkaWdpdC4gIFRoZSB0aHJlZSBzcGVjaWFs
Ci1tb2RlIGJpdHMgYWxzbyByZXF1aXJlIG9uZSBiaXQgZWFjaCwgYW5kIHRoZXkgYXJlIGFz
IGEgZ3JvdXAKLXJlcHJlc2VudGVkIGFzIGFub3RoZXIgb2N0YWwgZGlnaXQuICBIZXJlIGlz
IGhvdyB0aGUgYml0cyBhcmUgYXJyYW5nZWQsCi1zdGFydGluZyB3aXRoIHRoZSBsb3dlc3Qg
dmFsdWVkIGJpdDoKK0FzIGFuIGFsdGVybmF0aXZlIHRvIGdpdmluZyBhIHN5bWJvbGljIG1v
ZGUsIHlvdSBjYW4gZ2l2ZSBhbiBvY3RhbCAod2l0aCBiYXNlIDgpIG51bWJlciB0aGF0IHJl
cHJlc2VudHMgdGhlIG1vZGUuVGhpcyBudW1iZXIgaXMgYWx3YXlzIGludGVycHJldGVkIGlu
IG9jdGFsOyB5b3UgZG8gbm90IGhhdmUgdG8gYWRkIGEgbGVhZGluZyBAc2FtcHswfSwgYXMg
eW91IGRvIGluIEMuIE1vZGUgQHNhbXB7MDA1NX0gaXMgdGhlIHNhbWUgYXMgbW9kZSBAc2Ft
cHs1NX0uICBNb2RlcyBvZiBmaXZlIGRpZ2l0cyBvciBtb3JlLCBzdWNoIGFzIEBzYW1wezAw
MDU1fSwgaGF2ZSBhIHNwZWNpYWwgbWVhbmluZyBmb3IgZGlyZWN0b3JpZXMgIEB4cmVme0Rp
cmVjdG9yeSBTZXR1aWQgYW5kIFNldGdpZH0uKQorCitBIG51bWVyaWMgbW9kZSBpcyB1c3Vh
bGx5IHNob3J0ZXIgdGhhbiB0aGUgY29ycmVzcG9uZGluZyBzeW1ib2xpYyBtb2RlLCBidXQg
aXQgaXMgbGltaXRlZCBpbiB0aGF0IG5vcm1hbGx5IGl0IGNhbm5vdCB0YWtlIGludG8gYWNj
b3VudCB0aGUgcHJldmlvdXMgZmlsZSBtb2RlIGJpdHM7IGl0IGNhbiBvbmx5IHNldCB0aGVt
IGFic29sdXRlbHkuICBUaGUgc2V0LXVzZXItSUQgYW5kIHNldC1ncm91cC1JRCBiaXRzIG9m
IGRpcmVjdG9yaWVzIGFyZSBhbiBleGNlcHRpb24gdG8gdGhpcyBnZW5lcmFsIGxpbWl0YXRp
b24uICAgQHhyZWZ7RGlyZWN0b3J5IFNldHVpZCBhbmQgU2V0Z2lkfS4gIEFsc28sIG9wZXJh
dG9yIG51bWVyaWMgbW9kZXMgY2FuIHRha2UgcHJldmlvdXMgZmlsZSBtb2RlIGJpdHMgaW50
byBhY2NvdW50LiAgQHhyZWZ7T3BlcmF0b3IgTnVtZXJpYyBNb2Rlc30uCisKK1RoZSBvY3Rh
bCBub3RhdGlvbiBjYW4gYmUgZGVyaXZlZCBmcm9tIHRoZSBzeW1ib2xpYyBvbmUsIGFzIGFu
IGludGVybWVkaWF0ZSBzdGVwIHRyYW5zZm9ybWluZyBpdCBpbnRvIGEgYmluYXJ5IHN0cmlu
ZyAoMSksIHdoaWNoIGlzIHRoZW4gZWFzaWx5IGNoYW5nZWQgaW50byBvY3RhbCBiYXNlICgy
KToKKworKDEpRm9yIHRoZSBpbnRlcm1lZGlhdGUgc3RlcCB0aGUgQHNhbXB7cn0sQHNhbXB7
d30gYW5kIEBzYW1we3h9LXN5bWJvbHMgb2YgdGhlIHN5bWJvbGljIG5vdGF0aW9uIGFyZSBj
aGFuZ2VkIG91dCBhdCB0aGUgY29ycmVzcG9uZGluZyBwbGFjZSBieSBhIEBzYW1wezB9IG9y
IGEgQHNhbXB7MX0sIGFjY29yZGluZyB0byB3aGV0aGVyIHRoZSBiaXRzIGFyZSBjbGVhciBv
ciBzZXQgICh0aGlzIHdvcmtzIGFzIGxvbmcgYXMgdGhlcmUgYXJlIG5vIHNwZWNpYWwgbW9k
ZSBiaXRzLCBiZWNhdXNlIGV2ZXJ5IHBsYWNlIGJlbG9uZ3Mgc3BlY2lmaWNhbGx5IHRvIG9u
ZSBraW5kIG9mIGJpdCksIHRodXMgdHJhbnNmb3JtaW5nIGUuZy4gdGhlIHN0cmluZyBAc2Ft
cHtyd3hyLXhyLS19IGludG8gQHNhbXB7MTExMTAxMTAwfS5UaGVuIGluc3RlYWQgb2Ygb3Zl
cnJpZGluZyB0aGUgQHNhbXB7eH0tYml0cywgdGhlIHNwZWNpYWwgbW9kZSBiaXRzIGFyZSBy
ZXByZXNlbnRlZCBieSBncm91cGluZyB0aGVtIGF0IHRoZSBiZWdpbm5pbmcsIGluIHRoZSBv
cmRlciBzdWlkfGd1aWR8c3RpY2t5L3Jlc3RyaWN0ZWRfZGVsZXRpb24sIHRodXMgZS5nLiBk
ZXNjcmliaW5nIHN5bWJvbGljIEBzYW1we3J3c3IteHItdH0gYXMgQHNhbXB7MTAxMTExMTAx
MTAxfS4gCisKKygyKUV2ZXJ5IDMgZGlnaXRzIGNhbiB0aGVuIGJlIGdyb3VwZWQgdG9nZXRo
ZXIgYW5kIGRlc2NyaWJlZCBhcyBhbiBvY3RhbCBkaWdpdCwgZm9sbG93aW5nIHRoZSBsb2dp
YyB0aGF0IHRocmVlIGJpbmFyeSBkaWdpdHMgQHNhbXB7YWJjfSBhcmUgdHJhbnNsYXRlZCBp
bnRvIGFuIG9jdGFsIG51bWJlciBhKjJeMitiKjJeMStjKjJeMD1hKjQrYioyK2MqMSwgZS5n
LjoKIAogQGV4YW1wbGUKLVZhbHVlIGluICBDb3JyZXNwb25kaW5nCi1Nb2RlICAgICAgTW9k
ZSBCaXQKLQotICAgICAgICAgIE90aGVyIHVzZXJzIG5vdCBpbiB0aGUgZmlsZSdzIGdyb3Vw
OgotICAgMSAgICAgIEV4ZWN1dGUvc2VhcmNoCi0gICAyICAgICAgV3JpdGUKLSAgIDQgICAg
ICBSZWFkCi0KLSAgICAgICAgICBPdGhlciB1c2VycyBpbiB0aGUgZmlsZSdzIGdyb3VwOgot
ICAxMCAgICAgIEV4ZWN1dGUvc2VhcmNoCi0gIDIwICAgICAgV3JpdGUKLSAgNDAgICAgICBS
ZWFkCi0KLSAgICAgICAgICBUaGUgZmlsZSdzIG93bmVyOgotIDEwMCAgICAgIEV4ZWN1dGUv
c2VhcmNoCi0gMjAwICAgICAgV3JpdGUKLSA0MDAgICAgICBSZWFkCi0KLSAgICAgICAgICBT
cGVjaWFsIG1vZGUgYml0czoKLTEwMDAgICAgICBSZXN0cmljdGVkIGRlbGV0aW9uIGZsYWcg
b3Igc3RpY2t5IGJpdAotMjAwMCAgICAgIFNldCBncm91cCBJRCBvbiBleGVjdXRpb24KLTQw
MDAgICAgICBTZXQgdXNlciBJRCBvbiBleGVjdXRpb24KK2JpbmFyeQlvY3RhbAorMTAxCTUK
KzExMQk3CiswMTEJMwogQGVuZCBleGFtcGxlCiAKLUZvciBleGFtcGxlLCBudW1lcmljIG1v
ZGUgQHNhbXB7NDc1NX0gY29ycmVzcG9uZHMgdG8gc3ltYm9saWMgbW9kZQotQHNhbXB7dT1y
d3hzLGdvPXJ4fSwgYW5kIG51bWVyaWMgbW9kZSBAc2FtcHs2NjR9IGNvcnJlc3BvbmRzIHRv
IHN5bWJvbGljIG1vZGUKLUBzYW1we3VnPXJ3LG89cn0uICBOdW1lcmljIG1vZGUgQHNhbXB7
MH0gY29ycmVzcG9uZHMgdG8gc3ltYm9saWMgbW9kZQotQHNhbXB7YT19LgordGh1cyB0cmFu
c2Zvcm1pbmcgdGhlIGJpbmFyeSBAc2FtcHsxMDExMTExMDExMDF9IGZyb20gdGhlIGxhc3Qg
ZXhhbXBsZSBpbnRvIG9jdGFsIEBzYW1wezU3NTV9LgorCiAKIEBub2RlIE9wZXJhdG9yIE51
bWVyaWMgTW9kZXMKIEBzZWN0aW9uIE9wZXJhdG9yIE51bWVyaWMgTW9kZXMKLS0gCjEuOS4x
Cgo=
--------------574FB62A092744D601952522--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: 
References: <59F78DAE.9070305@HIDDEN>
In-Reply-To: <59F78DAE.9070305@HIDDEN>
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 27 Mar 2018 13:09:02 +0000
Resent-Message-ID: <handler.29069.B.152215612222622 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: 29069 <at> debbugs.gnu.org, assafgordon@HIDDEN
X-Debbugs-Original-To: bug-coreutils@HIDDEN, assafgordon@HIDDEN, 29069 <at> debbugs.gnu.org
Received: via spool by submit <at> debbugs.gnu.org id=B.152215612222622
          (code B ref -1); Tue, 27 Mar 2018 13:09:02 +0000
Received: (at submit) by debbugs.gnu.org; 27 Mar 2018 13:08:42 +0000
Received: from localhost ([127.0.0.1]:55309 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f0oLC-0005so-30
	for submit <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:08:42 -0400
Received: from eggs.gnu.org ([208.118.235.92]:37157)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1f0oLA-0005sb-Ik
 for submit <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:08:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1f0oL3-0007lg-Rt
 for submit <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:08:35 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: **
X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_50,DATE_IN_PAST_24_48,
 T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:46256)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <kalle@HIDDEN>)
 id 1f0oL3-0007lM-Nb
 for submit <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:08:33 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56353)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1f0oL2-0004fK-0v
 for bug-coreutils@HIDDEN; Tue, 27 Mar 2018 09:08:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kalle@HIDDEN>) id 1f0oKx-0007h3-0x
 for bug-coreutils@HIDDEN; Tue, 27 Mar 2018 09:08:32 -0400
Received: from mail.netzguerilla.net ([2a00:1828:2000:612::25]:55487)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <kalle@HIDDEN>)
 id 1f0oKw-0007fK-KH
 for bug-coreutils@HIDDEN; Tue, 27 Mar 2018 09:08:26 -0400
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 77845100015;
 Tue, 27 Mar 2018 15:08:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([217.11.57.120])
 by localhost (sal.netzguerilla.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id WHSRnme6r95I; Tue, 27 Mar 2018 15:08:20 +0200 (CEST)
Received: from localhost.localdomain.Speedport_W723_V_Typ_A_1_01_018
 (p200300DDFF237E0174DB496AC41E26B9.dip0.t-ipconnect.de
 [IPv6:2003:dd:ff23:7e01:74db:496a:c41e:26b9])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id CCDE2100019;
 Tue, 27 Mar 2018 15:08:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1522156099;
 bh=o+VjmQRZV+Q8fsp1wxr63ru1wCHUJKRdxYH7kEC1jgc=;
 h=From:Subject:To:Date:From;
 b=FgJfqwtO7sfJ9Bf2k9P1VLjUbHK/U2c05YnlEUAplSy/BwmpE3frd7gkqTjW0y6Eo
 2CnsE3v6+pNhJVcdue2CELTQIVojkJn7A5bjLlZVJ/ZxuzISyhYlgAKL6WTgMP/9/2
 iwL3s20ipvZRumVSo6Gtn3TVAQG/oEAxGdJeFzox7bLwjWz17hAwBFkxtULEkY8Y7H
 SgozIq54Y5l9U0po4ExfjPTOFCG3Wpideh3SqOjbvVamiNJYOHW7afLIwzKm7cOlUb
 TEvoaRmd3mzvbcK0ocCtSXIFcC8SMB8y+7ZNNKAXynLwkbWe+4G8/K5KxJRcAuwlvV
 lT+VIXMZ4jqvA==
From: kalle <kalle@HIDDEN>
Message-ID: <e29010d4-ef10-2eee-3655-968fe0817289@HIDDEN>
Date: Sun, 25 Mar 2018 16:43:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.5 (----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

hello people.
I once wrote some improvement proposals to the list.

assafgordon@HIDDEN wrote to me

"
You wrote many good suggestions and text improvements.

If you'd like to see them through, the best way is to
offer a patch suitable for inclusion.
For instructions on how to send such patch, please see
  https://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
  https://git.savannah.gnu.org/cgit/coreutils.git/tree/README-hacking

As your contribution is significant (more than 10 lines),
it'll also require copyright assignment (see
https://www.gnu.org/licenses/why-assign.html ).

If you prefer not to spend time on making such a patch, that is of
course completely fine. In that case, this will have to wait until
one of the maintainers (or another volunteer) decides to
spend the time required to incorporate these improvements.
"

Since then I extra learned git, to be able to give in the patches
myself. But for my last 2 mails sending in my patch proposals, no
response came...

here now for the 4th time again my patch proposal for chapter 27.3:

>From b250dcdaba02083a0174d9157c655f0dbb586ef6 Mon Sep 17 00:00:00 2001
From: kalle <kalle@HIDDEN>
Date: Wed, 3 Jan 2018 20:56:07 +0100
Subject: [PATCH] changed presentation in 'File permissions' in 'numeric
modes'

I described the numeric modes explaining it's octal representation and
how it is obtained from the symbolic notation.
---
=C2=A0doc/perm.texi | 64
++++++++++++++---------------------------------------------
=C2=A01 file changed, 15 insertions(+), 49 deletions(-)

diff --git a/doc/perm.texi b/doc/perm.texi
index c94c483..a514998 100644
--- a/doc/perm.texi
+++ b/doc/perm.texi
@@ -491,59 +491,25 @@ the file to all users.
=C2=A0@cindex numeric modes
=C2=A0@cindex file mode bits, numeric
=C2=A0@cindex octal numbers for file modes
-As an
-alternative to giving a symbolic mode, you can give an octal (base 8)
-number that represents the mode.
-This number is always interpreted in octal; you do not have to add a
-leading @samp{0}, as you do in C.=C2=A0 Mode @samp{0055} is the same as
-mode @samp{55}.=C2=A0 (However, modes of five digits or more, such as
-@samp{00055}, are sometimes special.=C2=A0 @xref{Directory Setuid and Se=
tgid}.)
-
-A numeric mode is usually shorter than the corresponding symbolic
-mode, but it is limited in that normally it cannot take into account the
-previous file mode bits; it can only set them absolutely.
-The set-user-ID and set-group-ID bits of directories are an exception
-to this general limitation.=C2=A0 @xref{Directory Setuid and Setgid}.
-Also, operator numeric modes can take previous file mode bits into
-account.=C2=A0 @xref{Operator Numeric Modes}.
-
-The permissions granted to the user,
-to other users in the file's group,
-and to other users not in the file's group each require three
-bits, which are represented as one octal digit.=C2=A0 The three special
-mode bits also require one bit each, and they are as a group
-represented as another octal digit.=C2=A0 Here is how the bits are arran=
ged,
-starting with the lowest valued bit:
+As an alternative to giving a symbolic mode, you can give an octal
(with base 8) number that represents the mode.This number is always
interpreted in octal; you do not have to add a leading @samp{0}, as you
do in C. Mode @samp{0055} is the same as mode @samp{55}.=C2=A0 Modes of f=
ive
digits or more, such as @samp{00055}, have a special meaning for
directories=C2=A0 @xref{Directory Setuid and Setgid}.)
+
+A numeric mode is usually shorter than the corresponding symbolic mode,
but it is limited in that normally it cannot take into account the
previous file mode bits; it can only set them absolutely.=C2=A0 The
set-user-ID and set-group-ID bits of directories are an exception to
this general limitation.=C2=A0=C2=A0 @xref{Directory Setuid and Setgid}.=C2=
=A0 Also,
operator numeric modes can take previous file mode bits into account.=C2=A0
@xref{Operator Numeric Modes}.
+
+The octal notation can be derived from the symbolic one, as an
intermediate step transforming it into a binary string (1), which is
then easily changed into octal base (2):
+
+(1)For the intermediate step the @samp{r},@samp{w} and @samp{x}-symbols
of the symbolic notation are changed out at the corresponding place by a
@samp{0} or a @samp{1}, according to whether the bits are clear or set=C2=
=A0
(this works as long as there are no special mode bits, because every
place belongs specifically to one kind of bit), thus transforming e.g.
the string @samp{rwxr-xr--} into @samp{111101100}.Then instead of
overriding the @samp{x}-bits, the special mode bits are represented by
grouping them at the beginning, in the order
suid|guid|sticky/restricted_deletion, thus e.g. describing symbolic
@samp{rwsr-xr-t} as @samp{101111101101}.
+
+(2)Every 3 digits can then be grouped together and described as an
octal digit, following the logic that three binary digits @samp{abc} are
translated into an octal number a*2^2+b*2^1+c*2^0=3Da*4+b*2+c*1, e.g.:
=C2=A0
=C2=A0@example
-Value in=C2=A0 Corresponding
-Mode=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mode Bit
-
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Other users not i=
n the file's group:
-=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Execute/search
-=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Write
-=C2=A0=C2=A0 4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Read
-
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Other users in th=
e file's group:
-=C2=A0 10=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Execute/search
-=C2=A0 20=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Write
-=C2=A0 40=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Read
-
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The file's owner:
- 100=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Execute/search
- 200=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Write
- 400=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Read
-
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Special mode bits=
:
-1000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Restricted deletion flag or sticky bi=
t
-2000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set group ID on execution
-4000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set user ID on execution
+binary=C2=A0=C2=A0=C2=A0 octal
+101=C2=A0=C2=A0=C2=A0 5
+111=C2=A0=C2=A0=C2=A0 7
+011=C2=A0=C2=A0=C2=A0 3
=C2=A0@end example
=C2=A0
-For example, numeric mode @samp{4755} corresponds to symbolic mode
-@samp{u=3Drwxs,go=3Drx}, and numeric mode @samp{664} corresponds to
symbolic mode
-@samp{ug=3Drw,o=3Dr}.=C2=A0 Numeric mode @samp{0} corresponds to symboli=
c mode
-@samp{a=3D}.
+thus transforming the binary @samp{101111101101} from the last example
into octal @samp{5755}.
+
=C2=A0
=C2=A0@node Operator Numeric Modes
=C2=A0@section Operator Numeric Modes
--=20
1.9.1

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: 
References: <59F78DAE.9070305@HIDDEN>
In-Reply-To: <59F78DAE.9070305@HIDDEN>
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 27 Mar 2018 13:09:02 +0000
Resent-Message-ID: <handler.29069.B29069.152215611222599 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: notabug
To: 29069 <at> debbugs.gnu.org, assafgordon@HIDDEN
X-Debbugs-Original-To: bug-coreutils@HIDDEN, assafgordon@HIDDEN, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.152215611222599
          (code B ref 29069); Tue, 27 Mar 2018 13:09:02 +0000
Received: (at 29069) by debbugs.gnu.org; 27 Mar 2018 13:08:32 +0000
Received: from localhost ([127.0.0.1]:55306 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f0oL1-0005sQ-N2
	for submit <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:08:32 -0400
Received: from mail.netzguerilla.net ([217.11.57.120]:49033)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1f0oKz-0005sC-GE
 for 29069 <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:08:30 -0400
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 77845100015;
 Tue, 27 Mar 2018 15:08:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([217.11.57.120])
 by localhost (sal.netzguerilla.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id WHSRnme6r95I; Tue, 27 Mar 2018 15:08:20 +0200 (CEST)
Received: from localhost.localdomain.Speedport_W723_V_Typ_A_1_01_018
 (p200300DDFF237E0174DB496AC41E26B9.dip0.t-ipconnect.de
 [IPv6:2003:dd:ff23:7e01:74db:496a:c41e:26b9])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id CCDE2100019;
 Tue, 27 Mar 2018 15:08:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1522156099;
 bh=o+VjmQRZV+Q8fsp1wxr63ru1wCHUJKRdxYH7kEC1jgc=;
 h=From:Subject:To:Date:From;
 b=FgJfqwtO7sfJ9Bf2k9P1VLjUbHK/U2c05YnlEUAplSy/BwmpE3frd7gkqTjW0y6Eo
 2CnsE3v6+pNhJVcdue2CELTQIVojkJn7A5bjLlZVJ/ZxuzISyhYlgAKL6WTgMP/9/2
 iwL3s20ipvZRumVSo6Gtn3TVAQG/oEAxGdJeFzox7bLwjWz17hAwBFkxtULEkY8Y7H
 SgozIq54Y5l9U0po4ExfjPTOFCG3Wpideh3SqOjbvVamiNJYOHW7afLIwzKm7cOlUb
 TEvoaRmd3mzvbcK0ocCtSXIFcC8SMB8y+7ZNNKAXynLwkbWe+4G8/K5KxJRcAuwlvV
 lT+VIXMZ4jqvA==
From: kalle <kalle@HIDDEN>
Message-ID: <e29010d4-ef10-2eee-3655-968fe0817289@HIDDEN>
Date: Sun, 25 Mar 2018 16:43:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

hello people.
I once wrote some improvement proposals to the list.

assafgordon@HIDDEN wrote to me

"
You wrote many good suggestions and text improvements.

If you'd like to see them through, the best way is to
offer a patch suitable for inclusion.
For instructions on how to send such patch, please see
  https://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
  https://git.savannah.gnu.org/cgit/coreutils.git/tree/README-hacking

As your contribution is significant (more than 10 lines),
it'll also require copyright assignment (see
https://www.gnu.org/licenses/why-assign.html ).

If you prefer not to spend time on making such a patch, that is of
course completely fine. In that case, this will have to wait until
one of the maintainers (or another volunteer) decides to
spend the time required to incorporate these improvements.
"

Since then I extra learned git, to be able to give in the patches
myself. But for my last 2 mails sending in my patch proposals, no
response came...

here now for the 4th time again my patch proposal for chapter 27.3:

>From b250dcdaba02083a0174d9157c655f0dbb586ef6 Mon Sep 17 00:00:00 2001
From: kalle <kalle@HIDDEN>
Date: Wed, 3 Jan 2018 20:56:07 +0100
Subject: [PATCH] changed presentation in 'File permissions' in 'numeric
modes'

I described the numeric modes explaining it's octal representation and
how it is obtained from the symbolic notation.
---
 doc/perm.texi | 64
++++++++++++++---------------------------------------------
 1 file changed, 15 insertions(+), 49 deletions(-)

diff --git a/doc/perm.texi b/doc/perm.texi
index c94c483..a514998 100644
--- a/doc/perm.texi
+++ b/doc/perm.texi
@@ -491,59 +491,25 @@ the file to all users.
 @cindex numeric modes
 @cindex file mode bits, numeric
 @cindex octal numbers for file modes
-As an
-alternative to giving a symbolic mode, you can give an octal (base 8)
-number that represents the mode.
-This number is always interpreted in octal; you do not have to add a
-leading @samp{0}, as you do in C.  Mode @samp{0055} is the same as
-mode @samp{55}.  (However, modes of five digits or more, such as
-@samp{00055}, are sometimes special.  @xref{Directory Setuid and Setgid}.)
-
-A numeric mode is usually shorter than the corresponding symbolic
-mode, but it is limited in that normally it cannot take into account the
-previous file mode bits; it can only set them absolutely.
-The set-user-ID and set-group-ID bits of directories are an exception
-to this general limitation.  @xref{Directory Setuid and Setgid}.
-Also, operator numeric modes can take previous file mode bits into
-account.  @xref{Operator Numeric Modes}.
-
-The permissions granted to the user,
-to other users in the file's group,
-and to other users not in the file's group each require three
-bits, which are represented as one octal digit.  The three special
-mode bits also require one bit each, and they are as a group
-represented as another octal digit.  Here is how the bits are arranged,
-starting with the lowest valued bit:
+As an alternative to giving a symbolic mode, you can give an octal
(with base 8) number that represents the mode.This number is always
interpreted in octal; you do not have to add a leading @samp{0}, as you
do in C. Mode @samp{0055} is the same as mode @samp{55}.  Modes of five
digits or more, such as @samp{00055}, have a special meaning for
directories  @xref{Directory Setuid and Setgid}.)
+
+A numeric mode is usually shorter than the corresponding symbolic mode,
but it is limited in that normally it cannot take into account the
previous file mode bits; it can only set them absolutely.  The
set-user-ID and set-group-ID bits of directories are an exception to
this general limitation.   @xref{Directory Setuid and Setgid}.  Also,
operator numeric modes can take previous file mode bits into account. 
@xref{Operator Numeric Modes}.
+
+The octal notation can be derived from the symbolic one, as an
intermediate step transforming it into a binary string (1), which is
then easily changed into octal base (2):
+
+(1)For the intermediate step the @samp{r},@samp{w} and @samp{x}-symbols
of the symbolic notation are changed out at the corresponding place by a
@samp{0} or a @samp{1}, according to whether the bits are clear or set 
(this works as long as there are no special mode bits, because every
place belongs specifically to one kind of bit), thus transforming e.g.
the string @samp{rwxr-xr--} into @samp{111101100}.Then instead of
overriding the @samp{x}-bits, the special mode bits are represented by
grouping them at the beginning, in the order
suid|guid|sticky/restricted_deletion, thus e.g. describing symbolic
@samp{rwsr-xr-t} as @samp{101111101101}.
+
+(2)Every 3 digits can then be grouped together and described as an
octal digit, following the logic that three binary digits @samp{abc} are
translated into an octal number a*2^2+b*2^1+c*2^0=a*4+b*2+c*1, e.g.:
 
 @example
-Value in  Corresponding
-Mode      Mode Bit
-
-          Other users not in the file's group:
-   1      Execute/search
-   2      Write
-   4      Read
-
-          Other users in the file's group:
-  10      Execute/search
-  20      Write
-  40      Read
-
-          The file's owner:
- 100      Execute/search
- 200      Write
- 400      Read
-
-          Special mode bits:
-1000      Restricted deletion flag or sticky bit
-2000      Set group ID on execution
-4000      Set user ID on execution
+binary    octal
+101    5
+111    7
+011    3
 @end example
 
-For example, numeric mode @samp{4755} corresponds to symbolic mode
-@samp{u=rwxs,go=rx}, and numeric mode @samp{664} corresponds to
symbolic mode
-@samp{ug=rw,o=r}.  Numeric mode @samp{0} corresponds to symbolic mode
-@samp{a=}.
+thus transforming the binary @samp{101111101101} from the last example
into octal @samp{5755}.
+
 
 @node Operator Numeric Modes
 @section Operator Numeric Modes
-- 
1.9.1

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 3 Apr 2018 15:35:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 03 11:35:26 2018
Received: from localhost ([127.0.0.1]:37264 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3Ny2-0007Oa-1S
	for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:35:26 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51082)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1f3Ny0-0007ON-NK
 for control <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:35:24 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id AC27516161A
 for <control <at> debbugs.gnu.org>; Tue,  3 Apr 2018 08:35:18 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id x-MR5QIypSnK for <control <at> debbugs.gnu.org>;
 Tue,  3 Apr 2018 08:35:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1561016161F
 for <control <at> debbugs.gnu.org>; Tue,  3 Apr 2018 08:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 1cnrAxB1AGSU for <control <at> debbugs.gnu.org>;
 Tue,  3 Apr 2018 08:35:18 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id F27F816161A
 for <control <at> debbugs.gnu.org>; Tue,  3 Apr 2018 08:35:17 -0700 (PDT)
To: GNU bug control <control <at> debbugs.gnu.org>
From: Paul Eggert <eggert@HIDDEN>
Subject: merge
Organization: UCLA Computer Science Department
Message-ID: <d72048e5-8be5-60db-97ba-976f85bd696d@HIDDEN>
Date: Tue, 3 Apr 2018 08:35:17 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

merge 29069 31043

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 03 Apr 2018 15:46:01 +0000
Resent-Message-ID: <handler.29069.B29069.152277031530170 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: patch notabug
To: kalle <kalle@HIDDEN>, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.152277031530170
          (code B ref 29069); Tue, 03 Apr 2018 15:46:01 +0000
Received: (at 29069) by debbugs.gnu.org; 3 Apr 2018 15:45:15 +0000
Received: from localhost ([127.0.0.1]:37275 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3O7X-0007pz-04
	for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:45:15 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:53016)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1f3O7V-0007jR-8V
 for 29069 <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:45:14 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9F5A816161E;
 Tue,  3 Apr 2018 08:45:07 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id EguBZGAZX3R1; Tue,  3 Apr 2018 08:45:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 92494161621;
 Tue,  3 Apr 2018 08:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id BiaJN264Epv7; Tue,  3 Apr 2018 08:45:06 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 76DDC16161E;
 Tue,  3 Apr 2018 08:45:06 -0700 (PDT)
References: <486ecfd6-e29f-71f1-936d-6e41e71c15ca@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <f29aabfe-bb18-cc2f-2557-314a08b45903@HIDDEN>
Date: Tue, 3 Apr 2018 08:45:06 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <486ecfd6-e29f-71f1-936d-6e41e71c15ca@HIDDEN>
Content-Type: multipart/mixed; boundary="------------03C9A079B000A2DF8F8DCBDB"
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

This is a multi-part message in MIME format.
--------------03C9A079B000A2DF8F8DCBDB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for mentioning the problem. However, I found the proposed rewrite 
to be more confusing than the original. I think part of the problem is 
that this is not really the place to explain octal notation; any reader 
who doesn't know octal before reading the manual is not likely to 
understand it even with the proposed rewrite. I think we should just 
give up and assume that the reader knows octal (if they don't they 
should be using symbolic modes). That being said, we could briefly give 
an example of how the individual bits are combined into an octal digit, 
and rearrange the description to make it more intuitive. I installed the 
attached patch to try to improve things.

I also merged Bug#31043 with Bug#29069 since they're the same topic.

--------------03C9A079B000A2DF8F8DCBDB
Content-Type: text/x-patch;
 name="0001-doc-Clarify-octal-bits-in-permissions.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="0001-doc-Clarify-octal-bits-in-permissions.patch"

From a20bf723b62bb54c32154c6bf0c7c4d9e6e8a708 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Tue, 3 Apr 2018 08:40:34 -0700
Subject: [PATCH] doc: Clarify octal bits in permissions

* doc/perm.texi (Numeric Modes): Briefly explain octal.
Reorder description to make it more intuitive (Bug#29069).
---
 doc/perm.texi | 66 +++++++++++++++++++++++++++++++----------------------------
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/doc/perm.texi b/doc/perm.texi
index af8fa3827..77ec1a59c 100644
--- a/doc/perm.texi
+++ b/doc/perm.texi
@@ -494,57 +494,61 @@ the file to all users.
 As an
 alternative to giving a symbolic mode, you can give an octal (base 8)
 number that represents the mode.
-This number is always interpreted in octal; you do not have to add a
-leading @samp{0}, as you do in C.  Mode @samp{0055} is the same as
-mode @samp{55}.  (However, modes of five digits or more, such as
-@samp{00055}, are sometimes special.  @xref{Directory Setuid and Setgid}.)
-
-A numeric mode is usually shorter than the corresponding symbolic
-mode, but it is limited in that normally it cannot take into account the
-previous file mode bits; it can only set them absolutely.
-The set-user-ID and set-group-ID bits of directories are an exception
-to this general limitation.  @xref{Directory Setuid and Setgid}.
-Also, operator numeric modes can take previous file mode bits into
-account.  @xref{Operator Numeric Modes}.
 
 The permissions granted to the user,
 to other users in the file's group,
 and to other users not in the file's group each require three
-bits, which are represented as one octal digit.  The three special
+bits: one bit for read, one for write, and one for execute/search permission.
+These three bits are represented as one octal digit;
+for example, if all three are present, the resulting 111 (in binary)
+is represented as the digit 7 (in octal).  The three special
 mode bits also require one bit each, and they are as a group
 represented as another octal digit.  Here is how the bits are arranged,
-starting with the lowest valued bit:
+starting with the highest valued bit:
 
 @example
 Value in  Corresponding
 Mode      Mode Bit
 
-          Other users not in the file's group:
-   1      Execute/search
-   2      Write
-   4      Read
-
-          Other users in the file's group:
-  10      Execute/search
-  20      Write
-  40      Read
+          Special mode bits:
+4000      Set user ID on execution
+2000      Set group ID on execution
+1000      Restricted deletion flag or sticky bit
 
           The file's owner:
- 100      Execute/search
- 200      Write
  400      Read
+ 200      Write
+ 100      Execute/search
 
-          Special mode bits:
-1000      Restricted deletion flag or sticky bit
-2000      Set group ID on execution
-4000      Set user ID on execution
+          Other users in the file's group:
+  40      Read
+  20      Write
+  10      Execute/search
+
+          Other users not in the file's group:
+   4      Read
+   2      Write
+   1      Execute/search
 @end example
 
-For example, numeric mode @samp{4755} corresponds to symbolic mode
-@samp{u=rwxs,go=rx}, and numeric mode @samp{664} corresponds to symbolic mode
+For example, numeric mode @samp{4751} corresponds to symbolic mode
+@samp{u=srwx,g=rx,o=x}, and numeric mode @samp{664} corresponds to symbolic mode
 @samp{ug=rw,o=r}.  Numeric mode @samp{0} corresponds to symbolic mode
 @samp{a=}.
 
+A numeric mode is usually shorter than the corresponding symbolic
+mode, but it is limited in that normally it cannot take into account the
+previous file mode bits; it can only set them absolutely.
+The set-user-ID and set-group-ID bits of directories are an exception
+to this general limitation.  @xref{Directory Setuid and Setgid}.
+Also, operator numeric modes can take previous file mode bits into
+account.  @xref{Operator Numeric Modes}.
+
+Numeric modes are always interpreted in octal; you do not have to add a
+leading @samp{0}, as you do in C@.  Mode @samp{0055} is the same as
+mode @samp{55}.  However, modes of five digits or more, such as
+@samp{00055}, are sometimes special (@pxref{Directory Setuid and Setgid}).
+
 @node Operator Numeric Modes
 @section Operator Numeric Modes
 
-- 
2.14.3


--------------03C9A079B000A2DF8F8DCBDB--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 03 Apr 2018 19:30:02 +0000
Resent-Message-ID: <handler.29069.B29069.152278378523787 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: patch notabug
To: Paul Eggert <eggert@HIDDEN>, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.152278378523787
          (code B ref 29069); Tue, 03 Apr 2018 19:30:02 +0000
Received: (at 29069) by debbugs.gnu.org; 3 Apr 2018 19:29:45 +0000
Received: from localhost ([127.0.0.1]:37362 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3Rcn-0006Bb-54
	for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 15:29:45 -0400
Received: from mail.netzguerilla.net ([217.11.57.120]:49741)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1f3Rcl-0006BM-F7
 for 29069 <at> debbugs.gnu.org; Tue, 03 Apr 2018 15:29:44 -0400
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 0F72110001A;
 Tue,  3 Apr 2018 21:29:37 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([IPv6:2a00:1828:2000:612::25])
 by localhost (sal.netzguerilla.net [IPv6:::1]) (amavisd-new, port 10024)
 with ESMTP id 2WEv_wAF3brn; Tue,  3 Apr 2018 21:29:35 +0200 (CEST)
Received: from [IPv6:2003:dd:ff23:7e01:6181:b30a:d43a:664a]
 (p200300DDFF237E016181B30AD43A664A.dip0.t-ipconnect.de
 [IPv6:2003:dd:ff23:7e01:6181:b30a:d43a:664a])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id B1828100018;
 Tue,  3 Apr 2018 21:29:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1522783775;
 bh=y9ba7RGmox6ZMXuMj6zX33odglW0z8ZdOQRFZhDHVdM=;
 h=Subject:To:References:From:Date:In-Reply-To:From;
 b=lJ7TS95SZx0q7rl9NBP8X2ZEnpjNRGgx9/ELUCQxNZDfObhQpzqlK7vmPBxlS9A52
 BcPtUzXw1Ps+oexxxck6DjrDNj2gb+2AkwoeZg1fNk0RWcNcAhbsKJMlnxjkPSSurq
 99uO2O0skDkVOXupVPZQC6vJKC+iFHjP9ehu5qdG1csGpvQ6Q66DodddRpPDAFA1fQ
 nhMM+N52BCF0HBmLtERzH0rS7Cs15ls5oQ4TaTuFHEf3/MH1UQ4JXMCKjwiXzl1Zx6
 gOSlvzMsCki69Am+TvlM9gGRjdn255anQePOITioxoWqlb1n8+eNqV9HyNfntomxTv
 D4VWR8un/qm4w==
References: <486ecfd6-e29f-71f1-936d-6e41e71c15ca@HIDDEN>
 <f29aabfe-bb18-cc2f-2557-314a08b45903@HIDDEN>
From: kalle <kalle@HIDDEN>
Message-ID: <a8540e0e-9121-4df8-8b8e-8ae79deab904@HIDDEN>
Date: Tue, 3 Apr 2018 21:29:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <f29aabfe-bb18-cc2f-2557-314a08b45903@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

hello,


Am 03.04.2018 um 17:45 schrieb Paul Eggert:
> Thanks for mentioning the problem.
so you see a problem there too?

 However, I found the proposed rewrite
> to be more confusing than the original. 
It may me that my way of building sentences is quite amendable. I'm not
a native english writer.
But what do you think of my teaching concept, to try to explain why a
`7' in `755' means =4+2+1=111=rwx="rwx for owner", which is assumed as
self-evident or intuitive in both the original text and your patch?			

I think part of the problem is
> that this is not really the place to explain octal notation;
maybe. But where would be a place, to formulate the problem `7=4+2+1'
more generally? and then to just refer to it?

 any reader
> who doesn't know octal before reading the manual is not likely to
> understand it even with the proposed rewrite.
Because of what, do you think?

 I think we should just
> give up and assume that the reader knows octal (if they don't they
> should be using symbolic modes) 
if they don't miss any important features..
but why already giving up? does it seem so impossible to find a more
newbie-friendly solution?

. That being said, we could briefly give
> an example of how the individual bits are combined into an octal digit,
> and rearrange the description to make it more intuitive. I installed the
> attached patch to try to improve things.
Why didn't you take over my correction from "are sometimes special" to
"have a special meaning for directories" ?
> 
> I also merged Bug#31043 with Bug#29069 since they're the same topic.
The problem was, that when writing  "Bug#29069" in the subject, nobody
responded to my patch proposal, which at the end was nearly to frustrating.

greetings,
kalle

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 03 Apr 2018 22:11:02 +0000
Resent-Message-ID: <handler.29069.B29069.152279343013131 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: patch notabug
To: kalle <kalle@HIDDEN>, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.152279343013131
          (code B ref 29069); Tue, 03 Apr 2018 22:11:02 +0000
Received: (at 29069) by debbugs.gnu.org; 3 Apr 2018 22:10:30 +0000
Received: from localhost ([127.0.0.1]:37425 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3U8M-0003Pj-EF
	for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 18:10:30 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52388)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1f3U8K-0003PX-OD
 for 29069 <at> debbugs.gnu.org; Tue, 03 Apr 2018 18:10:29 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 08FC316162D;
 Tue,  3 Apr 2018 15:10:23 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id XWKRoisaBalv; Tue,  3 Apr 2018 15:10:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 139BB161699;
 Tue,  3 Apr 2018 15:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id NgHiwskt4UGx; Tue,  3 Apr 2018 15:10:21 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id EBAB916162D;
 Tue,  3 Apr 2018 15:10:21 -0700 (PDT)
References: <486ecfd6-e29f-71f1-936d-6e41e71c15ca@HIDDEN>
 <f29aabfe-bb18-cc2f-2557-314a08b45903@HIDDEN>
 <a8540e0e-9121-4df8-8b8e-8ae79deab904@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <36583967-c081-07fb-cbce-a8226df73638@HIDDEN>
Date: Tue, 3 Apr 2018 15:10:21 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <a8540e0e-9121-4df8-8b8e-8ae79deab904@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 04/03/2018 12:29 PM, kalle wrote:
>
> But what do you think of my teaching concept, to try to explain why a
> `7' in `755' means =4+2+1=111=rwx="rwx for owner", which is assumed as
> self-evident or intuitive in both the original text and your patch?

I think it's out of place in the coreutils manual, just as (for example) 
the manual need not mention computer keyboard layouts in order to tell 
users how to type 'sort -r'. Assuming basic computer concepts simplifies 
the manual and makes it easier for typical users to read, which is a win.

> 		
> where would be a place, to formulate the problem `7=4+2+1'
> more generally?

One place would be:

https://en.wikipedia.org/wiki/Octal


> Why didn't you take over my correction from "are sometimes special" to
> "have a special meaning for directories" ?

I didn't think that was necessary, since the parenthesized 
cross-reference already mentioned "Directory". The main point here is 
that the leading "0" is not necessary, not that excess leading "0"s 
sometimes have special meanings.

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
Resent-From: kalle <kalle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 11 Apr 2018 12:45:02 +0000
Resent-Message-ID: <handler.29069.B29069.15234506935370 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: patch notabug
To: Paul Eggert <eggert@HIDDEN>, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.15234506935370
          (code B ref 29069); Wed, 11 Apr 2018 12:45:02 +0000
Received: (at 29069) by debbugs.gnu.org; 11 Apr 2018 12:44:53 +0000
Received: from localhost ([127.0.0.1]:45798 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f6F7N-0001OX-9b
	for submit <at> debbugs.gnu.org; Wed, 11 Apr 2018 08:44:53 -0400
Received: from mail.netzguerilla.net ([217.11.57.120]:60443)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kalle@HIDDEN>) id 1f6F7L-0001OK-Ix
 for 29069 <at> debbugs.gnu.org; Wed, 11 Apr 2018 08:44:52 -0400
Received: from localhost (localhost [127.0.0.1])
 by mail.netzguerilla.net (Postfix) with ESMTP id 5748310001A;
 Wed, 11 Apr 2018 14:44:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at netzguerilla.net
Received: from mail.netzguerilla.net ([217.11.57.120])
 by localhost (sal.netzguerilla.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XWDXQgqy1RSt; Wed, 11 Apr 2018 14:44:43 +0200 (CEST)
Received: from [IPv6:2003:dd:ff23:7e01:cd7a:cbd2:a890:5e13]
 (p200300DDFF237E01CD7ACBD2A8905E13.dip0.t-ipconnect.de
 [IPv6:2003:dd:ff23:7e01:cd7a:cbd2:a890:5e13])
 by mail.netzguerilla.net (Postfix) with ESMTPSA id 1A7E2100015;
 Wed, 11 Apr 2018 14:44:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=projektwerkstatt.de;
 s=fckp; t=1523450683;
 bh=sIyAB1CN6wDihuwFGIoywA3yE2buMZ3b8P1alTmv5eQ=;
 h=Subject:To:References:From:Date:In-Reply-To:From;
 b=E5GUK1DsqCGePnpnA/gnKuqa/BvQpD0V5dNvxAh4ufeW94Bb4Pe4VCSDKcFQ95iYx
 L3vVy1SQyUDbNepQo0eMmbYwsH9NTMs+6bhXOwPK1TYjixl+v6EXWBXI10REZfnGUk
 iUQM/ZP4dwn7nUW4qYTDAnBhb8RF2TAudPQ+Ne6seuVtak5SWT7iLEQSXp5Su7e535
 7DTS/2FIipBeD+wfBVORRG69Oxm6Xq2Mmm/ZOJnyLVawnCy9ellSGmZmAvcAhpDqfI
 v02xNWoRWafjUCFrq6LEs8xpn9HtRI4YnEBb8JCOO2a1tAVi4pamM/StegqGW3C4og
 OPEKqVlYhj3kg==
References: <486ecfd6-e29f-71f1-936d-6e41e71c15ca@HIDDEN>
 <f29aabfe-bb18-cc2f-2557-314a08b45903@HIDDEN>
 <a8540e0e-9121-4df8-8b8e-8ae79deab904@HIDDEN>
 <36583967-c081-07fb-cbce-a8226df73638@HIDDEN>
From: kalle <kalle@HIDDEN>
Message-ID: <4072cdbb-82b0-3b64-12de-f83c35720397@HIDDEN>
Date: Wed, 11 Apr 2018 14:44:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <36583967-c081-07fb-cbce-a8226df73638@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am 04.04.2018 um 00:10 schrieb Paul Eggert:
> On 04/03/2018 12:29 PM, kalle wrote:
>>
>> But what do you think of my teaching concept, to try to explain why a
>> `7' in `755' means =4+2+1=111=rwx="rwx for owner", which is assumed as
>> self-evident or intuitive in both the original text and your patch?
> 
> I think it's out of place in the coreutils manual, just as (for example)
> the manual need not mention computer keyboard layouts in order to tell
> users how to type 'sort -r'. Assuming basic computer concepts simplifies
> the manual and makes it easier for typical users to read, which is a win.

I find your example far away from the actual problem: computer keyboard
layouts and how to define them is important but much more  general than
'sort -r' and in my opinion it should be described somewhere (actually
keymaps(5),loadkeys(1) and so forth) and be referred to at crucial moments.
While for `File Permission', I don't even know if this methodology of
encoding information (I mean "symbolical notation rwx for owner =
symbolical notation rwx = symbolical notation 111= interpreting 111
numerically in binary = transforming to numerical octal 7") is just used
in this special case or is used more generally throughout the GNU
programs. In any case it is _not_ just octal, but a specific way of
translating numerical octal to a symbolic notation (and that's what I
tried to explain in my patch) even if some nerds knew it's meaning by
experience.
At least it should be referred to the place, where the concept is
explained. And referencing to the internet is non an elegant way, as it
could be the case, that the person doesn't have any access to it.

Assuming that new users necessarily know about this special way of using
octal numbers is simply newbie-unfriendly. Imagine someone starting to
learn `ls' or `mv' or just 'File Permissions' now directly being stuck
with this methodology.

What is this person expected to have read before starting learning how
to work with the CLI through documentation-systems as `info' or `man'
apart from complicated imperialist english language?

after my patch proposal, paul eggert wrote:
"I think part of the problem is that this is not really the place to
explain octal notation; any reader who doesn't know octal before reading
the manual is not likely to understand it even with the proposed
rewrite. I think we should just give up and assume that the reader knows
octal (if they don't they should be using symbolic modes)."

The more appropriate way imo would be to look up for a good place for a
explanation rather than "giving up" so quickly.

kalle

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 13 Apr 2018 19:56:02 +0000
Resent-Message-ID: <handler.29069.B29069.1523649329886 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29069
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: patch notabug
To: kalle <kalle@HIDDEN>, 29069 <at> debbugs.gnu.org
Received: via spool by 29069-submit <at> debbugs.gnu.org id=B29069.1523649329886
          (code B ref 29069); Fri, 13 Apr 2018 19:56:02 +0000
Received: (at 29069) by debbugs.gnu.org; 13 Apr 2018 19:55:29 +0000
Received: from localhost ([127.0.0.1]:50956 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f74nA-0000EE-Nw
	for submit <at> debbugs.gnu.org; Fri, 13 Apr 2018 15:55:28 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49182)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1f74n9-0000E2-51
 for 29069 <at> debbugs.gnu.org; Fri, 13 Apr 2018 15:55:27 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 39EFA161631;
 Fri, 13 Apr 2018 12:55:21 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id pGyoWNFD8oFe; Fri, 13 Apr 2018 12:55:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4A7AA161642;
 Fri, 13 Apr 2018 12:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id Wik7jEj4Le8M; Fri, 13 Apr 2018 12:55:20 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2DBC6161631;
 Fri, 13 Apr 2018 12:55:20 -0700 (PDT)
References: <486ecfd6-e29f-71f1-936d-6e41e71c15ca@HIDDEN>
 <f29aabfe-bb18-cc2f-2557-314a08b45903@HIDDEN>
 <a8540e0e-9121-4df8-8b8e-8ae79deab904@HIDDEN>
 <36583967-c081-07fb-cbce-a8226df73638@HIDDEN>
 <4072cdbb-82b0-3b64-12de-f83c35720397@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <c751d622-eb56-80e7-bb0f-982e92f3ba5a@HIDDEN>
Date: Fri, 13 Apr 2018 12:55:19 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <4072cdbb-82b0-3b64-12de-f83c35720397@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

On 04/11/2018 05:44 AM, kalle wrote:
> I don't even know if this methodology of
> encoding information (I mean "symbolical notation rwx for owner =
> symbolical notation rwx = symbolical notation 111= interpreting 111
> numerically in binary = transforming to numerical octal 7") is just used
> in this special case or is used more generally throughout the GNU
> programs.

The symbolic notation's primary use is in the core GNU (and POSIX) 
utilities. It was introduced in Unix (a predecessor to GNU/Linux) and is 
standardized by POSIX. The symbolic notation is not generally used 
elsewhere, so it's good to document it in the coreutils manual. In 
contrast, octal numbers are generally used throughout computing and 
mathematics, and we shouldn't have to explain them here.

I'd be more sympathetic if octal numbers were required. But users don't 
have to use them; they can use symbolic modes. That's what symbolic 
modes were invented for: to help users who don't understand or like 
octal. The documentation should exploit this, not fight it.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.