bug#21094: cp: add option to sort when copying
On 20/07/15 01:34, Pádraig Brady wrote: On 19/07/15 07:09, Steve Russell wrote: When performing a recursive copy of a large number of files it would be helpful to have an option to copy the files in each directory in sorted order of the file names. There are a couple of use cases for this. The first is to be able to easily observe the progress of the copy using the -v option. Currently, the random order of the copy means I can not tell how far the copy has progressed. On occasions I have seen cp -v display a top level directory starting with 'z' and assumed the copy was almost done only to see it start copying files from another directory earlier in the alphabet. The second use case is sometimes I would like to start working with the destination files before the copy has completed. For example if I see the destination has the top level directory foo, an ordered copy means I can work with directories that are alphabetically before foo knowing that they will not change. Another minor use case is some mp3 players ignore the file names and metadata and always play tracks in the order they appear in the directory. Usually the filesystems used by these players will order directories in the same order files are added. For content like eBooks where track order is critical, a sorted copy would be a useful workaround for the limitations of these players. Thanks for the suggestion. The implementation would be quite simple given that we already sort directory entries by inode number to improve performance (though note that that performance enhancement may not be effective going forward with newer file systems and SSDs). The implementation would leverage gnulib's SAVEDIR_SORT_NAME functionality. The interface would probably mirror tar's --sort option. I'm 55:45 for exposing this option to cp, install and maybe mv. Upon consideration I'm down to 50:50. For the progress use case, one can use rsync, or perhaps an explicit progress option in cp. For the mp3 order case, one can use tar --sort to do the transfer. thanks, Pádraig.
bug#21096: Useradd, usermod do not use the target to read groups from when using the -R parameter
Hi list,
I'm trying to generate a rootfs and am using a script to add users,
groups etc. I first add a group via groupadd -R ${ROOTFS_TARGET}
somegroup which works fine.
Using useradd with the -R parameter, to add a user also works as
expected, until i try to add the -a -G somegroup options. Using usermod
after creating the group and doing -a -G somegroup identically fails
informing us there is no such group, somegroup.
It appears both usermod and useradd use the local /etc/group rather then
what is supplied via the -R parameter. A workaround for now, is to use
chroot directly, chroot ${TARGET} usermod -a -G somegroup someuser, but
that only works if coreutils (or busybox (without useradd/usermod)) are
already installed on the target, which may not be there (yet/at all).
Am I doing something wrong or is this indeed a bug in the coreutils?
I'm using debian jessie's 8.23-4 on amd64
Olliver
--
Met vriendelijke groeten, Kind regards, 与亲切的问候
Olliver Schinagl
Research Development
Ultimaker B.V.
--
IMAGINE IT MAKE IT
Meet us online at Twitter http://twitter.com/ultimaker, Facebook
http://facebook.com/ultimaker, Google+ http://google.com/+Ultimaker
www.ultimaker.com
bug#21096: Useradd, usermod do not use the target to read groups from when using the -R parameter
Hello, On 07/20/2015 04:12 AM, Olliver Schinagl wrote: ... It appears both usermod and useradd use the local /etc/group rather then what is supplied via the -R parameter. ... Am I doing something wrong or is this indeed a bug in the coreutils? It might be a bug, but not in coreutils - these programs are not part of coreutils. I'm using debian jessie's 8.23-4 on amd64 It seems that in Debian, these programs are part of the 'passwd' package, whose source is maintained here (as upstream of the 'shadow' package): http://pkg-shadow.alioth.debian.org/features.php You could try asking here: http://pkg-shadow.alioth.debian.org/getinvolved.php regards, - assaf
bug#21094: cp: add option to sort when copying
Pádraig Brady p...@draigbrady.com writes: For the progress use case, one can use rsync, or perhaps an explicit progress option in cp. rsync also sorts. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
bug#21098: uname man page
tag 21098 notabug stop Hello, On 07/20/2015 03:26 PM, Norbert de Jonge wrote: Maybe someone has time and energy to make some minor improvements to uname's man page. The problem lies in the vagueness and similarity of the options -m, -p and -i, combined with the program's unpredictable output. The man-page could be re-worded, but, the values that are reported by uname are very system specific. The Coreutil FAQ contains an entry for uname: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#uname-is-system-specific And some past discussions contain more information: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14388 http://lists.gnu.org/archive/html/bug-coreutils/2003-10/msg00098.html http://lists.gnu.org/archive/html/bug-coreutils/2004-11/msg00032.html To make people's lives easier, the description for -m should be changed. I also think it would be useful to add to the description, in parentheses, e.g. x86_64, i686. [...] If you want to determine whether a system is 32-bit or 64-bit, use this option. mentioning x86_64/i686 in the documentation is Linux-kernel specific, and coreutils is not limited to Linux-kernel, and would be incorrect/misleading on other systems (e.g. on BSD systems the returned value is amd64). In practice, The values of 'uname' are not standardized over all OSes/hardwares. The recommended way is to first detect the system/kernel type (e.g. just 'uname'), and then decode the hardware type, using the values that are common to that kernel. An example to such code is given here: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14388#14 Now, that works on Ubuntu, but not on, for example, Arch. Ubuntu, Mint and probably also Debian, return the same thing for -m, -p and -i. I'm not familiar with Arch; some GNU/Linux distros return the values reported by the Linux Kernel, and GNU coreutils does not change that value. Other distros patch GNU coreutils (or the kernel?) to return other values. See related discussion here: http://lists.gnu.org/archive/html/bug-coreutils/2012-11/msg00173.html http://lists.gnu.org/archive/html/bug-coreutils/2012-11/msg00177.html I believe that if the kernel is detected as Linux, then the developer can assume that uname -m would suffice (based on known Linux kernel values) [other participants - please correct me if that's wrong]: e.g: test $(uname) = Linux \ test $(uname -m) = x86_64 \ echo 64bit-linux || echo other For some 'uname -m' values of common OSes (not just Linux-based), see here: http://pretest.nongnu.org/versions/ HTH, - assaf
bug#21098: uname man page
Maybe someone has time and energy to make some minor improvements to uname's man page. The problem lies in the vagueness and similarity of the options -m, -p and -i, combined with the program's unpredictable output. I think a good way to explain the problem is by giving an example. My example mentions proprietary software, but the problem occurs in many other settings. The game engine Unity can deploy to GNU/Linux. A game developer creates a 64-bit executable and a customer requests 32-bit support in a post on the game's Steam Community Hub. Someone mentions to the indie developer that a shell script that uses uname could do the trick. The developer looks at the uname man page, reads print the hardware platform for -i and decides to try this out on Ubuntu. It returns x86_64 for the developer's 64-bit machine. After a bit of reading about bash the result is something like: if [ `uname -i` = x86_64 ] then ./game_64 else ./game_32 fi Now, that works on Ubuntu, but not on, for example, Arch. Ubuntu, Mint and probably also Debian, return the same thing for -m, -p and -i. But, if I'm not mistaken, the only POSIX option of those three is -m: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html For -m, The Open Group's publication says Write the name of the hardware TYPE (emphasis mine). The GNU coreutils man page for uname says -m will print the machine hardware NAME, while -i says print the hardware PLATFORM. The latter /seems/ to be the most relevant option even though it's not. To make people's lives easier, the description for -m should be changed. I also think it would be useful to add to the description, in parentheses, e.g. x86_64, i686. The man page could also use a POSIX section. In fact, it would be better if the section that describes the options, near those three similar ones, would say which of those is the POSIX variant and maybe even that If you want to determine whether a system is 32-bit or 64-bit, use this option. Really. I really think we can't help out people enough. Even processor type (-p) returns x86_64 on many/most distros, and may (thus) also trick developers and users into thinking that's the thing they're looking for. Best regards, Norbert de Jonge
bug#21098: uname man page
On 07/20/2015 09:26 PM, Norbert de Jonge wrote: Maybe someone has time and energy to make some minor improvements to uname's man page. The problem lies in the vagueness and similarity of the options -m, -p and -i, combined with the program's unpredictable output. Thanks for the report. Additionally to Assaf's answer, I want to mention that the man page of GNU coreutils utilities is (almost) identically to the --help output which we want to keep terse. Actually the former is generated from the latter. At the end of the man page, there is the reference to the real documentation: The full documentation for uname is maintained as a Texinfo manual. If the info and uname programs are properly installed at your site, the command info '(coreutils) uname invocation' should give you access to the complete manual. Now let's look at -m, -p, and -i there: `-i' `--hardware-platform' Print the hardware platform name (sometimes called the hardware implementation). Print `unknown' if the kernel does not make this information easily available, as is the case with Linux kernels. `-m' `--machine' Print the machine hardware name (sometimes called the hardware class or hardware type). `-p' `--processor' Print the processor type (sometimes called the instruction set architecture or ISA). Print `unknown' if the kernel does not make this information easily available, as is the case with Linux kernels. Is this sufficient for you? Otherwise feel free to suggest a better wording - preferably as a git patch or a regular diff, but we could also wrap it into a proper patch for you. Thanks have a nice day, Berny
