bug#31055: Document ls -Ur -fr
(info "(coreutils) Sorting the output") says ‘-r’ ‘--reverse’ Reverse whatever the sorting method is—e.g., list files in reverse alphabetical order, youngest first, smallest first, or whatever. OK but mention 'whatever' doesn't mean -U, -f, because they are sorted in "unsorted" order. In fact perhaps trigger an error. Actually directory order is still an order, so in fact it is odd that -r is "broken" here.
bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
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.
bug#31049: Bug found? Running in docker container on amazon ec2
On 04/03/2018 06:16 PM, Matthew Fowkes wrote: >> root@4901abe58547:/app# tail -f /var/log/check* >> tail: unrecognized file system type 0x794c7630 for >> '/var/log/checkForClaimFiles.log'. please report this to >> bug-coreutils@gnu.org. reverting to polling Support for this file system type has been added in later versions of coreutils (8.25 and later). For details see here: https://www.gnu.org/software/coreutils/filesystems.html Have a nice day, Berny
bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
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
bug#31049: Bug found? Running in docker container on amazon ec2
Just launched a new server on ec2 and received this message when trying to watch a log file: > root@4901abe58547:/app# tail -f /var/log/check* > tail: unrecognized file system type 0x794c7630 for > '/var/log/checkForClaimFiles.log'. please report this to > bug-coreutils@gnu.org. reverting to polling
bug#29069: bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
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.
>From a20bf723b62bb54c32154c6bf0c7c4d9e6e8a708 Mon Sep 17 00:00:00 2001
From: Paul Eggert
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
bug#31038: mv copies in ls -r order
OK. Please on (info "(coreutils) cp invocation") at ‘-v’ ‘--verbose’ Print the name of each file before copying it. add: "(Note this reveals internal order of operations, often in ls -U order, thus occasionally appearing to be in ls, ls -t, ls -r, ls -rt etc. order.)" (I mean on the same page you do go into such details: ‘-a’ ‘--archive’ Preserve as much as possible of the structure and attributes of the original files in the copy (but do not attempt to preserve internal directory structure; i.e., ‘ls -U’ may list the entries in a copied directory in a different order). Try to preserve SELinux security context and extended attributes (xattr), but ignore any failure to do that and print no corresponding diagnostic. Equivalent to ‘-dR )
bug#31038: mv copies in ls -r order
On 04/03/2018 09:37 AM, 積丹尼 Dan Jacobson wrote: > OK maybe I was just looking at the latter half of > > $ sh O > /tmp > created directory '/var/tmp/y' > copied 'x/1' -> '/var/tmp/y/1' > copied 'x/2' -> '/var/tmp/y/2' > copied 'x/3' -> '/var/tmp/y/3' > copied 'x/4' -> '/var/tmp/y/4' > copied 'x/5' -> '/var/tmp/y/5' > copied 'x/6' -> '/var/tmp/y/6' > copied 'x/7' -> '/var/tmp/y/7' > copied 'x/8' -> '/var/tmp/y/8' > copied 'x/9' -> '/var/tmp/y/9' > removed 'x/9' > removed 'x/8' > removed 'x/7' > removed 'x/6' > removed 'x/5' > removed 'x/4' > removed 'x/3' > removed 'x/2' > removed 'x/1' Ah, so you're questioning the behavior of cross-volume moves, rather than same-volume (where mv has to do separate non-atomic steps instead of letting rename(2) do all the work). Please, when you report something, GIVE ALL THE DETAILS up front, rather than making us play guessing games at how to reproduce things. > removed directory 'x' > > $ cat O > set -eu > cd /tmp > mkdir x > cd x > seq 9|xargs touch > cd - > mv -v x /var/tmp/y That is NOT the same command that you documented in your original report (where you used a glob); rather, it is a single directory name, where mv has to recurse itself. Note that you have entirely changed the question from what I answered in the previous mail. My claim that POSIX requires mv to process things in command line order is still true, but here, the command line order is only a single directory, and there is no requirement in POSIX at the order of the contents within the directory are handled, only that all files within the directory eventually get reached. In fact, there is no reason at all that file names in a cross-volume move have to be visited in any particular order, so our choice is to favor any order that is demonstratably faster, followed by any order that is easier to code. It's easier to process directory entries in readdir() order (which is NOT necessarily sorted by filename); the only reason to perform the copies in an order different from readdir() order is if sorting things gives better performance (in fact, we've found that sorting files, not by name order, but by inode number, tends to give speedups for rotating disks, where visiting files in incrementing inode order tends to be faster than visiting files in readdir() order). But when it comes to removing files, we have to perform bookkeeping in order to carefully track which files need to be removed; and in that case, a LIFO list is the simplest coding technique. So, in your particular example, you touched nine files in order (which probably had the side effect that readdir() order, name order, and inode order all matched); once all nine files have been copied (using whichever order was most efficient, although for your example all three orders likely happened to be the same), then the removal is done by processing the internal list of what still needs work, and that list happens to be easiest in reverse order. Still, I stand by my claim that this is not a bug, and that there is nothing to change unless you can provide a benchmark that shows that doing things in a different order offers a noticeable speedup. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
bug#31038: mv copies in ls -r order
OK maybe I was just looking at the latter half of $ sh O /tmp created directory '/var/tmp/y' copied 'x/1' -> '/var/tmp/y/1' copied 'x/2' -> '/var/tmp/y/2' copied 'x/3' -> '/var/tmp/y/3' copied 'x/4' -> '/var/tmp/y/4' copied 'x/5' -> '/var/tmp/y/5' copied 'x/6' -> '/var/tmp/y/6' copied 'x/7' -> '/var/tmp/y/7' copied 'x/8' -> '/var/tmp/y/8' copied 'x/9' -> '/var/tmp/y/9' removed 'x/9' removed 'x/8' removed 'x/7' removed 'x/6' removed 'x/5' removed 'x/4' removed 'x/3' removed 'x/2' removed 'x/1' removed directory 'x' $ cat O set -eu cd /tmp mkdir x cd x seq 9|xargs touch cd - mv -v x /var/tmp/y
bug#31045: split -e missing in split 8.4 version
tag 31045 notabug thanks On 04/03/2018 05:59 AM, Abhijeet Patwari wrote: > Hi, > > I was using split 8.25 version. In my code, I have used split -e option. > After server upgrade, split also got upgraded and my code is giving error > at split -e. > > Kindly let me know what is the equivalent of split -e in 8.4. OR any > alternate solution for this. Coreutils 8.4 is NOT an upgrade, but a downgrade, in relation to 8.25. 'split -e' was added in coreutils 8.8 (commit be10739) (although the NEWS file forgot to mention it; -e was added at the same time as --number, but only --number was mentioned in the NEWS). Your solution, then, is to actually upgrade coreutils back up to a version that has the features you want, or to rewrite your script to not require the use of that feature as it is not portable to the bare minimum behavior that POSIX requires of split. But since we can't retroactively add features to older releases, there's no bug to fix here, so I'm closing this bug in the database. Feel free to add more comments on the topic, though, as needed. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
bug#31038: mv copies in ls -r order
tag 31038 notabug thanks On 04/03/2018 02:52 AM, 積丹尼 Dan Jacobson wrote: > $ mv -v dir1/* dir2 > reveals that mv works backwards, > copying in ls -r order. Not quite true. It copies the arguments in the order given on the command line (the * glob expands to a sorted list according to the current locale's sorting rules) into the directory specified as the final argument; this is NOT the same as 'ls -r' which lists ALL arguments in a reverse-sorted lists. For example: $ mkdir dir1 dir2 $ touch dir1/a dir1/b $ echo ls -r dira1/* dir2 ls -r dir1/a dir1/b dir2 $ ls -r dira1/* dir2 dir1/b dir1/a dir2: (which listed both entries under dir1 first, rather than listing dir2 first - that is, the glob expanded things in sorted order, then ls -r reversed files within the same directory to list b before a but did NOT reverse directories themselves). $ mv -v dir1/* dir2 'dir1/a' -> 'dir2/a' 'dir1/b' -> 'dir2/b' Here, mv processed all arguments in the order they were given (a before b), which is different from what you claim as the 'ls -r' behavior (b before a, even when the command line listed a before b). > Well OK, but why is that order better than the order of the arguments it > was given? Because treating the final argument as the destination directory is how it's been done for 40+ years, and so it was standardized that way. Changing it now would break users. If you don't like it, use: mv -v --target-directory dir2 dir1/* This is not a bug, so I'm marking it as such in the database. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
bug#31045: split -e missing in split 8.4 version
Hi, I was using split 8.25 version. In my code, I have used split -e option. After server upgrade, split also got upgraded and my code is giving error at split -e. Kindly let me know what is the equivalent of split -e in 8.4. OR any alternate solution for this. -- Regards, Abhijeet Patwari Mob. No. +91 8147811997
bug#31043: [PATCH] changed presentation in 'File permissions' in 'numeric, modes'
hello,
below a patch proposal of mine.
kalle
>From b250dcdaba02083a0174d9157c655f0dbb586ef6 Mon Sep 17 00:00:00 2001
From: kalle
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{01100}.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{10101101}.
+
+(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
+binaryoctal
+1015
+1117
+0113
@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{10101101} from the last example
into octal @samp{5755}.
+
@node Operator Numeric Modes
@section Operator Numeric Modes
--
1.9.1
bug#31038: mv copies in ls -r order
$ mv -v dir1/* dir2 reveals that mv works backwards, copying in ls -r order. Well OK, but why is that order better than the order of the arguments it was given?
