bug#33097: test has filetest -a but man page doesn't list it

2018-10-20 Thread Paul Eggert

Bernhard Voelker wrote:

I don't think we can remove that primary without breaking some scripts,
so it's probably best to document it.


I have the opposite impression. Any scripts using this confusing -a operator are 
already broken, and we should phase it out. Not that anybody actually *uses* 
coreutils "test -a".






bug#16669: inconsistent 'rm -ir' prompting behavior

2018-10-20 Thread Paul Eggert

Assaf Gordon wrote:

Was there ever a resolution (or a committed fix)
for the "rm -ir" issue in:
https://bugs.gnu.org/16669


Not yet. I'd leave the bug open.





bug#14456: This bug is still present and has nothing to do with a translation problem. It's an I18N bultibytes characters problem.

2018-10-20 Thread Paul Eggert

I reopened the bug report.





bug#17669: Fwd: Re: Solaris acl woes

2018-10-20 Thread Paul Eggert

Bernhard Voelker wrote:

Is that by any chance solve the problem ?

yes, possibly, although 'require_setfacl_' does not use different
setfacl/getfacl syntax for Solaris/*BSD.


It does not fix the problem. I just now built the development coreutils 
(8.30.19-8ea92) on Solaris 10 sparc with GCC 3.4.3 
(csl-sol210-3_4-branch+sol_rpath) in a /tmp swap filesystem, and 'make check' 
had problems with:


tests/cp/preserve-2
tests/cp/preserve-link
tests/cp/reflink-perm
tests/cp/src-base-dot
tests/id/zero
tests/mv/dup-source
tests/mv/part-fail
tests/mv/part-symlink





bug#14456: This bug is still present and has nothing to do with a translation problem. It's an I18N bultibytes characters problem.

2018-10-20 Thread Errembault Philippe
I had forgotten about this problem, but it is still present in the version 8.25 
present on the linux mint 18.3 distribution I'm using right now.This has 
absolutely nothing to do with a translation problem. It is related with the 
I18N multibytes string processing.
As you can see, the line with the word «répertoire» is one character shorter 
because the «é» occupies 2 bytes in UTF-8.


bug#9594: 27.3 Numeric modes (File permissions): Special mode bits assume file is regular

2018-10-20 Thread Paul Eggert

Philippe Cloutier wrote:


Please clarify why this was closed.


It was closed primarily because no specific wording fix was proposed.

I looked at the bug report again, and don't agree that the old wording was wrong 
or even misleading. It's merely a summary table, there's a lot of explanatory 
text before the table, and we shouldn't clutter the table with another copy of 
the explanation. That being said, the explanatory text can be improved and the 
summary table can be abbreviated even further by removing the phrase "on 
execution" which seems to be the primary point of the original bug report. I 
installed the attached.
From 8ea92f2a1d76b224624e9770444de49c58c3cd33 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 20 Oct 2018 10:45:35 -0700
Subject: [PATCH] doc: tidy up setuid commentary
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/perm.texi (Mode Structure): Improve wording.
(Numeric Modes): Don’t say “on execution” (Bug#9594).
---
 doc/perm.texi | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/doc/perm.texi b/doc/perm.texi
index 77ec1a59c..78f0f0e4a 100644
--- a/doc/perm.texi
+++ b/doc/perm.texi
@@ -70,38 +70,36 @@ In addition to the three sets of three permissions listed 
above, the
 file mode bits have three special components, which affect only
 executable files (programs) and, on most systems, directories:
 
-@enumerate
-@item
+@table @asis
+@item The @dfn{set-user-ID bit} (@dfn{setuid bit}).
 @cindex set-user-ID
 @cindex setuid
-Set the process's effective user ID to that of the file upon execution
-(called the @dfn{set-user-ID bit}, or sometimes the @dfn{setuid bit}).
+On execution, set the process's effective user ID to that of the file.
 For directories on a few systems, give files created in the directory
 the same owner as the directory, no matter who creates them, and set
 the set-user-ID bit of newly-created subdirectories.
-@item
+
+@item The @dfn{set-group-ID bit} (@dfn{setgid bit}).
 @cindex set-group-ID
 @cindex setgid
-Set the process's effective group ID to that of the file upon execution
-(called the @dfn{set-group-ID bit}, or sometimes the @dfn{setgid bit}).
+On execution, set the process's effective group ID to that of the file.
 For directories on most systems, give files created in the directory
 the same group as the directory, no matter what group the user who
 creates them is in, and set the set-group-ID bit of newly-created
 subdirectories.
-@item
+
+@item The @dfn{restricted deletion flag} or @dfn{sticky bit}.
 @cindex sticky
 @cindex swap space, saving text image in
 @cindex text image, saving in swap space
 @cindex restricted deletion flag
 Prevent unprivileged users from removing or renaming a file in a directory
-unless they own the file or the directory; this is called the
-@dfn{restricted deletion flag} for the directory, and is commonly
+unless they own the file or the directory; this is commonly
 found on world-writable directories like @file{/tmp}.
-
 For regular files on some older systems, save the program's text image on the
-swap device so it will load more quickly when run; this is called the
-@dfn{sticky bit}.
-@end enumerate
+swap device so it will load more quickly when run, so that the image
+is ``sticky''.
+@end table
 
 In addition to the file mode bits listed above, there may be file attributes
 specific to the file system, e.g., access control lists (ACLs), whether a
@@ -511,8 +509,8 @@ Value in  Corresponding
 Mode  Mode Bit
 
   Special mode bits:
-4000  Set user ID on execution
-2000  Set group ID on execution
+4000  Set user ID
+2000  Set group ID
 1000  Restricted deletion flag or sticky bit
 
   The file's owner:
-- 
2.17.1



bug#17669: Fwd: Re: Solaris acl woes

2018-10-20 Thread Bernhard Voelker
On 10/20/18 5:30 AM, Assaf Gordon wrote:
> (triaging old bugs)
> 
> Hello,
> 
> This bug ( https://bugs.gnu.org/17669 ) deals
> with ACL test failures on Solaris for coreutils 8.22 .
> 
> Shortly after the release of 8.22 (but few months before this
> bug was submitted), Bernard pushed this:
> 
> 
> commit 5d7591d0edf0dd31c2daa195ee766c1383b89f4c
> Author: Bernhard Voelker 
> Date:   Fri Jan 10 16:48:25 2014 +0100
> 
>   tests: improve test for a working setfacl
>   Prompted by a test framework failure of tests/mkdir/p-acl.sh on armv7l:
>   The previous test for a working setfacl was not sufficient in some
>   circumstances.
> 
> 
> https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5d7591d0edf0dd31c2daa195ee766c1383b89f4c
> 
> 
> Is that by any chance solve the problem ?

yes, possibly, although 'require_setfacl_' does not use different
setfacl/getfacl syntax for Solaris/*BSD.

> (is this even still a problem?)

sorry, I don't have a Solaris system here, and your CFARM doesn't have
xattr-devel installed.

Thanks & have a nice day,
Berny





bug#9594: 27.3 Numeric modes (File permissions): Special mode bits assume file is regular

2018-10-20 Thread Philippe Cloutier

Hi Assaf,

On 18-10-15 10 h 07, Assaf Gordon wrote:

close 9594
retitle 9594 doc: expand 27.3 Numeric modes (File permissions)
stop

(triaging old bugs)

Hello,

On 25/09/11 07:57 AM, Filipus Klutiero wrote:

Le 2011-09-25 00:11, Paul Eggert a écrit :

On 09/24/11 14:33, Filipus Klutiero wrote:


These correspondences assume that the file is a regular file.

Not really: for example, the phrase "execute/search"
refers to execution (for regular files) and search
(for directories), and "Restricted deletion flag or sticky bit"
is talking about directories (for deletion) and regular
files (for sticky bit).

Sorry if the body didn't specify, but I was only referring to special mode 
bits. And indeed, one of them is OK.


With no further correspondence in 7 years, I'm closing this bug.



Please clarify why this was closed. I still see the bug in Debian 9's coreutils 
8.26-3. Was this fixed since?



Discussion can continue by replying to this thread.

regards,
 - assaf



--
Philippe Cloutier
http://www.philippecloutier.com






bug#14971: acknowledged by developer (Re: bug#14971: split man page table mushed)

2018-10-20 Thread Michael Albinus
積丹尼 Dan Jacobson  writes:

> Say, can we get the final information just from this email next time,
> just like in Debian. Where one doesn't need to click on the link to see
> how the bug was solved.

Well, we plan to merge with Debian's debbugs sources. This should
improve also messages like this.

However, this won't happen next days; first we need to set up the new
debbugs.gnu.org machine.

Best regards, Michael.





bug#14971: acknowledged by developer (Re: bug#14971: split man page table mushed)

2018-10-20 Thread 積丹尼 Dan Jacobson
Say, can we get the final information just from this email next time,
just like in Debian. Where one doesn't need to click on the link to see
how the bug was solved.


> "GbTS" == GNU bug Tracking System  writes:
GbTS> This is an automatic notification regarding your bug report
GbTS> #14971: split man page table mushed,
GbTS> which was filed against the coreutils package.

GbTS> Thank you for your report, which has now been closed.
GbTS> You can view the full report at
GbTS> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14971

GbTS> If you require further information, please followup to 
14...@debbugs.gnu.org.

GbTS> debbugs.gnu.org maintainers
GbTS> (administrator, GNU bugs database)