bug#59461: please help me

[Bernhard Voelker]

tag 59461 notabug
close 59461
stop

On 11/21/22 10:21, 林兴隆 wrote:

OS:  Rocky Linux release 9.0 (Blue Onyx)
kenel:   5.14.0-70.22.1.el9_0.x86_64
Docker： 20.10.21, build baeda1f
Docker-Compose： v2.11.2

I use docker compose to run a container activemq，The contents are as 
follows，Error encountered，How can I solve it？please help me.

version: '3'
services:
   nacos:
 image: webcenter/activemq
 container_name: activemq
 hostname: activemq
 restart: always
 deploy:
   mode: replicated
   replicas: 1
   resources:
 limits:
   cpus: '2'
   memory: 2G
 reservations:
   memory: 200M
 env_file:
   - /data/activemq/env/activemq.env
 ports:
   - "8161:8161"
   - "61613:61613"
   - "61616:61616"
   - "1883:1883"
   - /data/activemq/data:/data/activemq
   - /data/activemq/logs:/var/log/activemq
①
②
③
④


Please avoid screenshots of textual terminal text: it's bloat, it's hard to
copy/paste to reproduce, and may therefore be ignored on this mailing list.

AFAICS, there's no error related to the GNU coreutils in the files you sent.
Instead, there are error messages of other software, e.g. search for "CRIT".
You may get better support for the actual error in forums or mailing lists
of the software which emits those errors.

Re. coreutils, there's only this warning which probably tempted you to send
this bug report:

> tail: unrecognized file system type 0x794c7630 for ‘dock2.log’. please
> report this to bug-coreutils@gnu.org. reverting to polling

That docker image obviously uses a quite old coreutils version:
overlayfs - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.1 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

As this is not a bug in our software, I'm hereby closing this issue in our bug 
tracker.

Have a nice day,
Berny

bug#60512: tail: unrecognized file system type 0x794c7630

[Bernhard Voelker]

tag 60512 notabug
close 60512
stop

On 1/3/23 10:27, 闵续 wrote:

tail: unrecognized file system type 0x794c7630 for ‘douyin.search.api.log’.
please report this to bug-coreutils@gnu.org. reverting to polling


Thanks for the report.

That docker image seems to use a quite old coreutils version:
'overlayfs' - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.1 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#61248: uniq --unique needs examples

[Bernhard Voelker]

On 2/3/23 08:12, Dan Jacobson wrote:

uniq INFO page says:
‘-u’
‘--unique’
  Discard the last line that would be output for a repeated input
  group.  When used by itself, this option causes ‘uniq’ to print
  unique lines, and nothing else.

This really needs some examples, to help people understand what it means.


While an example is always nice, isn't the last part of the above exactly
telling what it's doing?

  $ printf '%s\n' a a a b c c | uniq -u
  b

Admittedly, the --help output is both much shorter and clearer:

-u, --unique  only print unique lines

Have a nice day,
Berny

bug#61530: sha256sum check single file in a mutiple sha sum text file

[Bernhard Voelker]

tag 61530 notabug
close 61530
stop

On 2/15/23 14:28, Andreas Löw wrote:

Hello,

I want to check a single file for correct sha256. All the files of my
directory are included in a sha256 text file named allsha256.

The sha256sum always checks all files included in the allsha256 file,
even if I write:

sha256sum myfile -c allsha256

It reports a warning 'no correct formatted line was found for myfile'
and later it reports 'myfile OK'

Regards,
Andreas


The *sum utilities always check all files given in a checksum file(s).
That means once you've passed the -c option, the utility will treat all
further arguments as the name of files with checksums - no matter if the
file appears before or after the -c option:

  $ sha256sum README NEWS> checksum1
  $ sha256sum TODO configure > checksum2
  $ sha256sum checksum1 -c checksum2
  README: OK
  NEWS: OK
  TODO: OK
  configure: OK

To achieve what you want, you have to pass only the checksum line of the
file you want, e.g.:

  $ grep myfile allsha256s | sha256sum -c -
  myfile: OK

Therefore, I'm hereby marking this as not-a-bug in our bug tracker.

Have a nice day,
Berny

bug#63732: Tailing Difficulities

[Bernhard Voelker]

tag 63732 notabug
close 63732
stop

On 5/26/23 02:26, Greg Carter via GNU coreutils Bug Reports wrote:

Got this when executing `tail -f install/MYSYBASE.log` for an SAP ASE
message log (a text file) with a Docker container:
```
tail: unrecognized file system type 0x794c7630 for 'install/MYSYBASE.log'.
please report this to bug-coreutils@gnu.org. reverting to polling
```

Thanks for the report.

That docker image seems to use a quite old coreutils version:
'overlayfs' - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.3 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#64326: Some more info about rm bug

[Bernhard Voelker]

tag 64326 notabug
close 64326
stop

On 6/28/23 19:33, Chris Elvidge wrote:
> On 28/06/2023 16:41, Arsen Arsenović via GNU coreutils Bug Reports wrote:
>> Hi,
>>
>> LitHack  writes:
>>
>>> Basically what it doing is that it doesn't recognise (-) this as a file
>>> name part even when using (\-). This bug will work on most of utilities
>>> like cat, cp etc
>>
>> This is simply how argument parsing and shell syntax work.  'rm \-abc'
>> is equivalent to just 'rm -abc', which is parsed as 'rm -a -b -c'.  To
>> delete a file with a dash at the start of its name, use 'rm ./-file' and
>> similar.
>>
>> Hope that helps, have a lovely day.

> Or rm -- -abc
>
> The "double-dash" signals "end of options"

And finally: FAQ #11 - #13:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#How-do-I-remove-files-that-start-with-a-dash_003f

I'm hereby closing this issue as not-a-bug.

Have a nice day,
Berny

bug#64540: [PATCH] od: exit out on failure to write to stdout

[Bernhard Voelker]

On 7/15/23 23:08, Pádraig Brady wrote:

The attached patch-set addresses two classes of issue:
1. Doubled error messages upon write errors
2. Continued processing upon write errors  (the orig problem reported).


Nice work!

Patch 1:

> --- /dev/null
> +++ b/tests/misc/write-errors.sh
> @@ -0,0 +1,70 @@

> +if ! test -w /dev/full || ! test -c /dev/full; then
> +  skip_ 'Need /dev/full'

Other tests use a slightly different skip message:
  skip_ '/dev/full is required'

I'd favor the latter, so that we don't miss it once we'd like
to factor it out to a require_dev_full in init.cfg.

Re. patch 002:

> all: avoid repeated diagnostic upon write error
>
> * cfg.mk (sc_some_programs_must_avoid_exit_failure): Adjust to
> avoid false positive.
> (sc_prohibit_exit_write_error): A new syntax check to prohibit
> open coding error(..., "write error"); instead directiing to use...

s/ii/i/

> --- a/src/system.h
> +++ b/src/system.h
> @@ -762,6 +762,14 @@ The following directory is part of the cycle:\n  %s\n"), 
\
>  } \
>while (0)
>
> +static inline void
> +write_error (void)
> +{
> +  fflush (stdout);/* Ensure nothing buffered that might induce an error. 
*/
> +  clearerr (stdout);  /* To avoid extraneous diagnostic from close_stdout.  
*/
> +  error (EXIT_FAILURE, errno, _("write error"));
> +}

Hmm, fflush could theoretically change errno, couldn't it?
In that case, error() would give a wrong diagnostic.
FWIW: `man clearerr` states that this function doesn't touch errno.

Thanks & have a nice day,
Berny

bug#66176: 9.4 root test fails: tests/rm/ext3-perf tests/rm/ext3-perf.sh

[Bernhard Voelker]

On 9/23/23 18:35, Jeffrey Cliff wrote:

Test suite told me to send this report in so here we are.

environment : custom LFS (GNM)
coreutils: 9.4
gcc: (GCC) 13.2.0



> FAIL: tests/rm/ext3-perf
> 
> [...]
>
> ++ date +%s
> + start=1698065263
> + mkdir d
> + cd d
> + xargs touch
> + seq 40
> + test -f 1
> + test -f 40
> + cd ..
> + ok=1
> + test 1 = 1
> +++ date +%s
> ++ expr 1698065541 - 1698065263
> + setup_duration=278
> + echo creating a 40-entry directory took 278 seconds
> creating a 40-entry directory took 278 seconds
> + test 60 -lt 278
> + threshold_seconds=278
> ++ date +%s
> + start=1698065541
> + timeout 278s rm -rf d
> + err=124
> +++ date +%s
> ++ expr 1698065819 - 1698065541
> + duration=278
> + case $err in
> + fail=1
> + echo rm took longer than 278 seconds
> rm took longer than 278 seconds
> + echo removing a 40-entry directory took 278 seconds
> removing a 40-entry directory took 278 seconds
> + Exit 1

Hmm, that seems to be a rather slow system.
On my desktop system on ext4 here, it is:
  creating a 40-entry directory took 6 seconds
  removing a 40-entry directory took 4 seconds

The test measures the time for the creation, and uses it to verify
that the removal is faster.

Depending on other activities on the system during creation vs. that during
the deletion, the test might fail.

Is it always reproducible on that system, or was this just a one-off?

Have a nice day,
Berny

bug#62572: cp --no-clobber behavior has changed

[Bernhard Voelker]

On 12/15/23 21:13, Michael Stone wrote:

On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:

Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.)


Whether the implementation is race-prone or not is an internal thing.
I think we're currently discussing more on a user-perspective level.

IIUC then the question is whether `cp -n` should continue to behave like
the (new) `cp --update=none` which returns EXIT_SUCCESS.

Regardless what other implementations do, when reading the -n description
from a user's point of view:

  -n, --no-clobber do not overwrite an existing file (overrides a
 -u or previous -i option). See also --update

then I'd expect the tool to just skip existing files like `rsync 
--ignore-existing`
does.  In that regard I would be surprised if skipping files would result in an 
error.
Well, I would understand if there'd be a '--no-clobber=fail' option.

As Kamil added the option in 2009, I'd assume that the same patch was already
active in RHEL versions for quite some longer time.
Now changing the exit code feels kind of rough.

Therefore, from a pure user's perspective and regarding many years of 
precedence,
I am 80:20 for reverting the exit code change.

Have a nice day,
Berny

bug#68866: man page description of pwd command has error I guess

[Bernhard Voelker]

tag 68866 notabug
close 68866
stop

On 2/1/24 04:09, Seungchul Lee wrote:

man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.


'man pwd' and 'env pwd --help' also tells:

  NOTE: your shell may have its own version of pwd, which usually supersedes
  the version described here.  Please refer to your shell's documentation
  for details about the options it supports.

Are you sure that you are running pwd(1) from GNU coreutils, or that of the 
shell?

  $ pwd# pwd of the shell
  /home/berny/osc

  $ env pwd# pwd of GNU coreutils
  /media/osc

  $ /usr/bin/pwd   # pwd of GNU coreutils
  /media/osc

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/17/24 07:10, Paul Eggert wrote:

Although removing that "mv --swap" implementation was a win, I don't
think we can simply delegate this to util-linux's exch command.


I still have some headache adding this.

This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.

Now, extending "exchange" to more arguments is confusing and the
use is not intuitive:
  mv -v --exchange  a b c d

An "exchange" can literally only be applied to 2 files,
and 'exch' is IMO fine.

I have the gut feeling that we didn't think through all cases,
and that some might be surprising, e.g.:

  $ mkdir d; echo 1 > a; echo 2 > d/a
  $ src/mv --exchange a a a a d/a

versus

  $ src/mv --exchange a a a a d/a

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/20/24 21:56, Paul Eggert wrote:

On 3/20/24 12:43, Bernhard Voelker wrote:


This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.


Yes, that's mv's original sin, which we cannot realistically change now.


I wouldn't go that far that it was a sin.  It's useful and people got
used to it without having to think about it.


I have the gut feeling that we didn't think through all cases,
and that some might be surprising, e.g.:

    $ mkdir d; echo 1 > a; echo 2 > d/a
    $ src/mv --exchange a a a a d/a

versus

    $ src/mv --exchange a a a a d/a


I don't understand the word "versus" here, as the two examples look the
same to me.


sorry, I messed the example up.

  $ echo 1 > a
  $ mkdir d
  $ echo 2 > d/a
  $ src/mv -v --exchange a a a d
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  $ cat a
  2
  $ src/mv -v --exchange a a a d
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  $ cat a
  1
  $ src/mv -v --exchange a a a a d
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  $ cat a
  1

I remember some implementation where mv(1) really was just a rename(2),
which failed when crossing file systems.  Was it some HP-UX or Solaris mv(1)?
mv(1) has learned to copy+delete over time, which is what people would
expect from a "move".

My point is that "exchange" is a different functionality.
It's well somehow belonging and related to what renameat(2) is doing in the 
kernel,
and therefore it comes in handy that we can simply call it with an additional 
flag.
Yet it's IMO a different operation.  I bet there had been discussions whether
to create a new syscall, but apparently it was easier to put it with a flag
into an existing one.  Fine for the kernel.

On userland OTOH, we have broader choice.
Karel did his choice in util-linux for exch(1), and coreutils could expose
the same functionality.

For other feature requests, we were much more reluctant in coreutils ... for
good reasons: feature bloat, maintainability, etc.

So I'm asking myself what is different this time?
- The feature already exists -> util-linux.
- Okay, we're using the same syscall, renameat(2) -> it's tempting.
- How large is the useful overlap with the existing code of mv(1)?
  Not much: no traditional rename nor copy.
- How large is the useful overlap with the existing options/modes of mv(1)?
  - exchange contradicts --backup,
  - exchange is not useful together with options working with a regular
rename of copy, at least: --update, -Z, -n.
  - not sure if exchange works well together with -f.

I'm currently only 20:80 for adding it to mv(1).
The functionality is cool, but do we need to press it into mv(1) with so many
incompatibilities just because it's requiring renameat(2) we already use?
Maybe to consider: One tool for one thing ... means another tool for another 
thing.

Again, I have the gut feeling that we've missed some cases to think about.
And once the feature would be in ...

Furthermore, why does exchange not work to exchange a regular with a directory 
file?
We've all learned that everything's a file, so it cannot be explained to users 
that
exchanging a regular file with a directory doesn't work.

Finally, the test cases are very sparse: no cases with different owners, 
different
directory permissions, different file types (if we know already f<->d doesn't 
work),
triggering races, etc.

I don't really want to object to add it, but I find it quite odd as of today.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/21/24 00:56, Paul Eggert wrote:

On 3/20/24 15:53, Bernhard Voelker wrote:
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.


There's another which is not consistent with/without --exchange:

  $ src/mv -v a a
  src/mv: 'a' and 'a' are the same file

  $ src/mv -v --exchange a a
  renamed 'a' -> 'a'

RENAME_EXCHANGE is allowed (but useless?) for 1 file.

BTW: shouldn't the -v diagnostic better say "exchanged 'a' <-> 'a'"
because that's what happened?


    - not sure if exchange works well together with -f.


What problems do you see there?


it's up to the tests to proof that.


why does exchange not work to exchange a regular with a
directory file?


It works. I don't see a problem there.

$ touch a
$ mkdir d
$ ./mv -T --exchange a d
$ ls -ld a d
drwxr-xr-x. 2 eggert eggert 4096 Mar 20 16:52 a
-rw-r--r--. 1 eggert eggert0 Mar 20 16:52 d


indeed, it works.  It seems my test was wrong, sorry.


Finally, the test cases are very sparse:


Feel free to add some. :-)


Unfortunately, I cannot currently spend as much time as I'd love to.

It seems that -i is skipped:

  $ src/mv -iv --exchange a b
  renamed 'a' -> 'b'

As far as I know Padraig would like to do the next release very soon,
so I would recommend to not hurrying this one into it, and instead
ironing all out after the release.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/23/24 02:44, Paul Eggert wrote:

I installed the attached patches to do the above. (Basically, the
problem was that my earlier patches were too ambitious; these patches
scale things back to avoid some optimizations so that mv --exchange is
more like ordinary mv.)

The first patch simplifies the code (and fixes a diagnostic to be more
useful) without otherwise changing behavior; it's more of a refactoring.
The second patch does the real work.


Thanks.

We should put adding more tests on our TODO list still.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/22/24 11:22, Karel Zak wrote:
> On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:>> On 
userland OTOH, we have broader choice.
>> Karel did his choice in util-linux for exch(1), and coreutils could expose
>> the same functionality.
>>
>> For other feature requests, we were much more reluctant in coreutils ... for
>> good reasons: feature bloat, maintainability, etc.
>>
>> So I'm asking myself what is different this time?
>> - The feature already exists -> util-linux.
>
> Note that we can move exch(1) from util-linux to coreutils if, at the
> end of the brainstorming session, the conclusion will be that mv(1) is
> a bad choice :-)

I'd be for that as well, because ...

>> I'm currently only 20:80 for adding it to mv(1).
>
> I think the functionality will be lost in the mv(1) for many users.

... that's a fair point.

The code for the functionality is in copy.c, so - as with mv.c/cp.c/install.c -
we could have a exch.c using just that part, and thus expose a clearer interface
to the users.

Have a nice day,
Berny

bug#70298: uname -i returns unknown since fedora 38

[Bernhard Voelker]

On 4/9/24 2:21 PM, Pádraig Brady wrote:

Thanks for looking at this.
 From the Fedora side, they dropped a Fedora specific patch for Fedora 38.

https://bugzilla.redhat.com/show_bug.cgi?id=548834
https://bugzilla.redhat.com/show_bug.cgi?id=2208048


FWIW: OpenSUSE still has that patch which was kept in sync with Fedora for 
years:

  
https://build.opensuse.org/projects/openSUSE:Factory/packages/coreutils/files/coreutils-sysinfo.patch?expand=1

I have no strong opinion about it, but I guess some (build?) scripts rely on 
this.

Have a nice day,
Berny

bug#71895: Test failure in Coreutils 9.4 [During LFS Build]

[Bernhard Voelker]

On 7/2/24 10:10, Pádraig Brady wrote:

Note some of the output of the test seemed to be elided,
so I wasn't able to see exactly the line that failed
(No space left on device is an expected case and not the issue here).


Latest 'returns_', i.e., after gnulib commit 7b8fe0cfbde, seem to have improved 
the
'set -x' behavior.  We have that commit already included in the gnulib submodule
of coreutils, so it would also be good to test with a distribution tarball from
latest git.

Have a nice day,
Berny

bug#8909: tests/ls/stat-free-color: fails on OpenSuSE 11.4

[Bernhard Voelker]

Hi,

`make check` of coreutils.git (latest commit  is 
18bd9ce40ae05d52543fc9c5a5fdf4f82d13068d) on an OpenSuSE 11.4

host fails (everything else was ok/skipped):


FAIL: ls/stat-free-color (exit: 1)
==

++ initial_cwd_=/home/berny/coreutils/tests
++ fail=0
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /home/berny/coreutils/tests gt-stat-free-color.
+++ case $# in
+++ destdir_=/home/berny/coreutils/tests
+++ template_=gt-stat-free-color.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ case $template_ in
 unset TMPDIR
 mktemp -d -t -p /home/berny/coreutils/tests gt-stat-free-color.
+++ d=/home/berny/coreutils/tests/gt-stat-free-color.07ux
+++ case $d in
+++ test -d /home/berny/coreutils/tests/gt-stat-free-color.07ux
 ls -dgo /home/berny/coreutils/tests/gt-stat-free-color.07ux
 tr S -
+++ perms='drwx-- 2 4096 Jun 21 09:24 
/home/berny/coreutils/tests/gt-stat-free-color.07ux'

+++ case $perms in
+++ test 0 = 0
+++ echo /home/berny/coreutils/tests/gt-stat-free-color.07ux
+++ return
++ test_dir_=/home/berny/coreutils/tests/gt-stat-free-color.07ux
++ cd /home/berny/coreutils/tests/gt-stat-free-color.07ux
++ gl_init_sh_nl_='
'
++ IFS='
'
++ for sig_ in 1 2 3 13 15
+++ expr 1 + 128
++ eval 'trap '\''Exit 129'\'' 1'
+++ trap 'Exit 129' 1
++ for sig_ in 1 2 3 13 15
+++ expr 2 + 128
++ eval 'trap '\''Exit 130'\'' 2'
+++ trap 'Exit 130' 2
++ for sig_ in 1 2 3 13 15
+++ expr 3 + 128
++ eval 'trap '\''Exit 131'\'' 3'
+++ trap 'Exit 131' 3
++ for sig_ in 1 2 3 13 15
+++ expr 13 + 128
++ eval 'trap '\''Exit 141'\'' 13'
+++ trap 'Exit 141' 13
++ for sig_ in 1 2 3 13 15
+++ expr 15 + 128
++ eval 'trap '\''Exit 143'\'' 15'
+++ trap 'Exit 143' 15
++ trap remove_tmp_ 0
+ path_prepend_ ../src
+ test 1 '!=' 0
+ path_dir_=../src
+ case $path_dir_ in
++ cd /home/berny/coreutils/tests/../src
++ echo /home/berny/coreutils/src
+ abs_path_dir_=/home/berny/coreutils/src
+ case $abs_path_dir_ in
+ 
PATH=/home/berny/coreutils/src:/home/berny/coreutils/src:/usr/lib64/mpi/gcc/openmpi/bin:/home/berny/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin

+ create_exe_shims_ /home/berny/coreutils/src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ ls
+ test yes = yes
+ local i
+ for i in '$*'
+ env ls --version
ls (GNU coreutils) 8.12.99-18bd
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
.

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.
+ require_strace_ stat
+ test 1 = 1
+ strace -V
+ strace -qe stat echo
+ require_dirent_d_type_
+ python
+ python /home/berny/coreutils/tests/d_type-check
+ for i in 1 2 3
+ ln -s nowhere dangle-1
+ for i in 1 2 3
+ ln -s nowhere dangle-2
+ for i in 1 2 3
+ ln -s nowhere dangle-3
+ cat
++ dircolors -b color-without-stat
+ eval 
'LS_COLORS='\''rs=0:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=00:su=00:sg=00:ca=00:tw=00:ow=00:st=00:ex=00:mh=00:'\'';' 
export LS_COLORS
++ 
LS_COLORS='rs=0:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=00:su=00:sg=00:ca=00:tw=00:ow=00:st=00:ex=00:mh=00:'

++ export LS_COLORS
+ strace -o log -e stat,lstat,stat64,lstat64 ls --color=always .
color-without-stat
dangle-1
dangle-2
dangle-3
log
++ wc -l
+ n_lines=5
+ case $n_lines in
+ fail=1
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ remove_tmp_
+ __st=1
+ cleanup_
+ :
+ cd /home/berny/coreutils/tests
+ chmod -R u+rwx /home/berny/coreutils/tests/gt-stat-free-color.07ux
+ rm -rf /home/berny/coreutils/tests/gt-stat-free-color.07ux
+ exit 1

How can I help?

Have a nice day,
Berny

bug#8909: tests/ls/stat-free-color: fails on OpenSuSE 11.4

[Bernhard Voelker]

On 06/21/2011 03:41 PM, Jim Meyering wrote:

Bernhard Voelker wrote:
...

LS_COLORS='rs=0:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=00:su=00:sg=00:ca=00:tw=00:ow=00:st=00:ex=00:mh=00:'
++ export LS_COLORS
+ strace -o log -e stat,lstat,stat64,lstat64 ls --color=always .
color-without-stat
dangle-1
dangle-2
dangle-3
log
++ wc -l
+ n_lines=5
+ case $n_lines in
+ fail=1

...

How can I help?


Thanks for testing and the report.
If you apply the patch below and rerun the test like this,

 make check -C tests TESTS=ls/stat-free-color VERBOSE=yes

then the offending strace output should help understand where
the extra stat calls are coming from.

For reference, I get this single call on Fedora 15:

 stat(".", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0

diff --git a/tests/ls/stat-free-color b/tests/ls/stat-free-color
index b1c4744..a1f6418 100755
--- a/tests/ls/stat-free-color
+++ b/tests/ls/stat-free-color
@@ -55,7 +55,7 @@ n_lines=$(wc -l<  log)
  # Expect one or two stat calls.
  case $n_lines in
1|2) ;;
-  *) fail=1 ;;
+  *) fail=1; cat log;;
  esac

  Exit $fail

--

It might be useful to see the entire strace output, too.
To get that, remove the "-e stat,lstat,stat64,lstat64" argument
from the strace invocation, and rerun the test.


The output of both runs is attached.
stat("/usr/lib64/mpi/gcc/openmpi/lib64") and friends is the culprit.

I can't remember to have anything un-OpenSuSE-11.4-like in my toolchain.

To me it seems that the test should count the difference of the
number of stat,lstat,stat64,lstat64 calls when run
  a) as a dummy:  ls --color=always --help
and
  b) for ".": ls --color=always .


Have a nice day,
Berny
make: Entering directory `/media/sdb5/berny/coreutils/tests'
make  check-TESTS
make[1]: Entering directory `/media/sdb5/berny/coreutils/tests'
make[2]: Entering directory `/media/sdb5/berny/coreutils/tests'
FAIL: ls/stat-free-color
==
   GNU coreutils 8.12.99-18bd: tests/test-suite.log   
==

1 of 1 test failed.  

.. contents:: :depth: 2


FAIL: ls/stat-free-color (exit: 1)
==

++ initial_cwd_=/media/sdb5/berny/coreutils/tests
++ fail=0
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /media/sdb5/berny/coreutils/tests gt-stat-free-color.
+++ case $# in
+++ destdir_=/media/sdb5/berny/coreutils/tests
+++ template_=gt-stat-free-color.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ case $template_ in
 unset TMPDIR
 mktemp -d -t -p /media/sdb5/berny/coreutils/tests gt-stat-free-color.
+++ d=/media/sdb5/berny/coreutils/tests/gt-stat-free-color.2L9D
+++ case $d in
+++ test -d /media/sdb5/berny/coreutils/tests/gt-stat-free-color.2L9D
 ls -dgo /media/sdb5/berny/coreutils/tests/gt-stat-free-color.2L9D
 tr S -
+++ perms='drwx-- 2 4096 Jun 21 15:51 
/media/sdb5/berny/coreutils/tests/gt-stat-free-color.2L9D'
+++ case $perms in
+++ test 0 = 0
+++ echo /media/sdb5/berny/coreutils/tests/gt-stat-free-color.2L9D
+++ return
++ test_dir_=/media/sdb5/berny/coreutils/tests/gt-stat-free-color.2L9D
++ cd /media/sdb5/berny/coreutils/tests/gt-stat-free-color.2L9D
++ gl_init_sh_nl_='
'
++ IFS='
'
++ for sig_ in 1 2 3 13 15
+++ expr 1 + 128
++ eval 'trap '\''Exit 129'\'' 1'
+++ trap 'Exit 129' 1
++ for sig_ in 1 2 3 13 15
+++ expr 2 + 128
++ eval 'trap '\''Exit 130'\'' 2'
+++ trap 'Exit 130' 2
++ for sig_ in 1 2 3 13 15
+++ expr 3 + 128
++ eval 'trap '\''Exit 131'\'' 3'
+++ trap 'Exit 131' 3
++ for sig_ in 1 2 3 13 15
+++ expr 13 + 128
++ eval 'trap '\''Exit 141'\'' 13'
+++ trap 'Exit 141' 13
++ for sig_ in 1 2 3 13 15
+++ expr 15 + 128
++ eval 'trap '\''Exit 143'\'' 15'
+++ trap 'Exit 143' 15
++ trap remove_tmp_ 0
+ path_prepend_ ../src
+ test 1 '!=' 0
+ path_dir_=../src
+ case $path_dir_ in
++ cd /media/sdb5/berny/coreutils/tests/../src
++ echo /media/sdb5/berny/coreutils/src
+ abs_path_dir_=/media/sdb5/berny/coreutils/src
+ case $abs_path_dir_ in
+ 
PATH=/media/sdb5/berny/coreutils/src:/home/berny/coreutils/src:/usr/lib64/mpi/gcc/openmpi/bin:/home/berny/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin
+ create_exe_shims_ /media/sdb5/berny/coreutils/src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ ls
+ test yes = yes
+ local i
+ for i in '$*'
+ env ls --version
ls (GNU coreutils) 8.12.99-18bd
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu

bug#8909: tests/ls/stat-free-color: fails on OpenSuSE 11.4

[Bernhard Voelker]

On 06/21/2011 04:16 PM, Jim Meyering wrote:

Bernhard Voelker wrote:

On 06/21/2011 03:41 PM, Jim Meyering wrote:

It might be useful to see the entire strace output, too.
To get that, remove the "-e stat,lstat,stat64,lstat64" argument
from the strace invocation, and rerun the test.


The output of both runs is attached.
stat("/usr/lib64/mpi/gcc/openmpi/lib64") and friends is the culprit.


Thanks.


I can't remember to have anything un-OpenSuSE-11.4-like in my toolchain.

To me it seems that the test should count the difference of the
number of stat,lstat,stat64,lstat64 calls when run
   a) as a dummy:  ls --color=always --help
and
   b) for ".": ls --color=always .


That would be more robust.
Do you feel like writing the patch?


Attached try #1 and the log.

I'm not sure about x-platform calculation, but I guess
  n_lines=$(expr $n_lines - $n_lines_help)
is okay - actually I saw it somewhere else in tests/.

Have a nice day,
Berny
>From 3a6e0abab8eaa92922ce4cb1cfdfda278ccde8a6 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Tue, 21 Jun 2011 16:26:50 +0200
Subject: [PATCH] tests: ls/stat-free-color: count only the number of stat calls compared to --help

* tests/ls/stat-free-color: The system may do additional stat calls upon loading
(seen on OpenSuSE-11.4). Count only the number of stat calls compared to --help.
---
 tests/ls/stat-free-color |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/tests/ls/stat-free-color b/tests/ls/stat-free-color
index b1c4744..03ef6e1 100755
--- a/tests/ls/stat-free-color
+++ b/tests/ls/stat-free-color
@@ -49,9 +49,15 @@ MULTIHARDLINK 00
 EOF
 eval $(dircolors -b color-without-stat)
 
+# The system may do additional *stat*()s upon loading.
+# Count the difference compared to a dummy "--help" call.
+strace -o log -e stat,lstat,stat64,lstat64 ls --color=always --help >/dev/null 2>&1 || fail=1
+n_lines_help=$(wc -l < log)
 strace -o log -e stat,lstat,stat64,lstat64 ls --color=always . || fail=1
 n_lines=$(wc -l < log)
 
+n_lines=$(expr $n_lines - $n_lines_help)
+
 # Expect one or two stat calls.
 case $n_lines in
   1|2) ;;
-- 
1.7.3.4

PASS: ls/stat-free-color (exit: 0)
==

++ initial_cwd_=/media/sdb5/berny/coreutils/tests
++ fail=0
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /media/sdb5/berny/coreutils/tests gt-stat-free-color.
+++ case $# in
+++ destdir_=/media/sdb5/berny/coreutils/tests
+++ template_=gt-stat-free-color.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ case $template_ in
 unset TMPDIR
 mktemp -d -t -p /media/sdb5/berny/coreutils/tests gt-stat-free-color.
+++ d=/media/sdb5/berny/coreutils/tests/gt-stat-free-color.knck
+++ case $d in
+++ test -d /media/sdb5/berny/coreutils/tests/gt-stat-free-color.knck
 ls -dgo /media/sdb5/berny/coreutils/tests/gt-stat-free-color.knck
 tr S -
+++ perms='drwx-- 2 4096 Jun 21 16:25 /media/sdb5/berny/coreutils/tests/gt-stat-free-color.knck'
+++ case $perms in
+++ test 0 = 0
+++ echo /media/sdb5/berny/coreutils/tests/gt-stat-free-color.knck
+++ return
++ test_dir_=/media/sdb5/berny/coreutils/tests/gt-stat-free-color.knck
++ cd /media/sdb5/berny/coreutils/tests/gt-stat-free-color.knck
++ gl_init_sh_nl_='
'
++ IFS=' 	
'
++ for sig_ in 1 2 3 13 15
+++ expr 1 + 128
++ eval 'trap '\''Exit 129'\'' 1'
+++ trap 'Exit 129' 1
++ for sig_ in 1 2 3 13 15
+++ expr 2 + 128
++ eval 'trap '\''Exit 130'\'' 2'
+++ trap 'Exit 130' 2
++ for sig_ in 1 2 3 13 15
+++ expr 3 + 128
++ eval 'trap '\''Exit 131'\'' 3'
+++ trap 'Exit 131' 3
++ for sig_ in 1 2 3 13 15
+++ expr 13 + 128
++ eval 'trap '\''Exit 141'\'' 13'
+++ trap 'Exit 141' 13
++ for sig_ in 1 2 3 13 15
+++ expr 15 + 128
++ eval 'trap '\''Exit 143'\'' 15'
+++ trap 'Exit 143' 15
++ trap remove_tmp_ 0
+ path_prepend_ ../src
+ test 1 '!=' 0
+ path_dir_=../src
+ case $path_dir_ in
++ cd /media/sdb5/berny/coreutils/tests/../src
++ echo /media/sdb5/berny/coreutils/src
+ abs_path_dir_=/media/sdb5/berny/coreutils/src
+ case $abs_path_dir_ in
+ PATH=/media/sdb5/berny/coreutils/src:/home/berny/coreutils/src:/usr/lib64/mpi/gcc/openmpi/bin:/home/berny/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin
+ create_exe_shims_ /media/sdb5/berny/coreutils/src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ ls
+ test yes = yes
+ local i
+ for i in '$*'
+ env ls --version
ls (GNU coreutils) 8.12.99-18bd
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free softw

bug#10064: sort: sometimes segfault with certain limits (using prlimit)

[Bernhard Voelker]

For the new support of util-linux' prlimit to allow a command to be run
http://article.gmane.org/gmane.linux.utilities.util-linux-ng/5039
I tried to find a useful example for the manpage.

I found a nice, huge file to feed sort with - /dev/zero, and
my first try was to let the command be killed after 1 CPU second:

  ./prlimit --cpu=1 sort -u /dev/zero

Don't do that! ;-)

But as I was playing around with various different limits and values,
sort sometimes segfaulted:

  prlimit --stack=1000 --memlock=10 --rss=1000 sort -u /dev/zero

Well, mostly (4/5 times) sort got correctly "Killed",
but a segfault smells.

Similar limit values (not leading to OOM killer) behaved the same.

OpenSuSE-11.4, sort from git.

Have a nice day,
Berny

bug#10064: sort: sometimes segfault with certain limits (using prlimit)

[Bernhard Voelker]

On 11/16/2011 07:32 PM, Paul Eggert wrote:

On 11/16/11 09:25, Bernhard Voelker wrote:


   prlimit --stack=1000 --memlock=10 --rss=1000 sort -u /dev/zero

Well, mostly (4/5 times) sort got correctly "Killed",
but a segfault smells.


Sorry, I don't have prlimit and don't know what it does.
Can you reproduce the problem with a standard shell
and ulimit?

Or failing that, can you give a backtrace?


prlimit is a new command from util-linux around the prlimit(2) system call.

Comparing the prlimit values with that of ulimit shed some light on it.
Used to the kilobyte unit of ulimit (but prlimit using bytes),
I gave it extreme low limits. The prlimit syscall even rounded
my --rss and --stack values down to 0, see man prlimit(2):

   RLIMIT_MEMLOCK
  The maximum number of bytes of memory that may be locked 
into RAM.
  In effect this limit is rounded down to the nearest 
multiple  of

  the  system page size.

$ ulimit -a
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 31578
max locked memory   (kbytes, -l) 9
max memory size (kbytes, -m) 0
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 0
cpu time   (seconds, -t) unlimited
max user processes  (-u) 31578
virtual memory  (kbytes, -v) 4927920
file locks  (-x) unlimited

It seems that "sort" isn't even involved yet:
(gdb) bt
#0  0x7fb58936f712 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#1  0x7fb58936baf8 in _start () from /lib64/ld-linux-x86-64.so.2
#2  0x0003 in ?? ()
#3  0x7fff49b2b469 in ?? ()
#4  0x7fff49b2b482 in ?? ()
#5  0x7fff49b2b485 in ?? ()
#6  0x in ?? ()

So this is not a coreutils bug.

However, now I'm really confused about ulimit vs. prlimit(2) values:

$ bash -c 'ulimit -m'
3447088
$ prlimit --rss --rss=1000 --rss bash -c 'ulimit -m'
RESOURCE DESCRIPTION SOFT  HARD UNITS
RSS  max resident set size 3529818112 unlimited pages
RSS  max resident set size   1000  1000 pages
0
$ prlimit --rss --rss=1000 --rss prlimit --rss
RESOURCE DESCRIPTION SOFT  HARD UNITS
RSS  max resident set size 3529818112 unlimited pages
RSS  max resident set size   1000  1000 pages
RESOURCE DESCRIPTION   SOFT HARD UNITS
RSS  max resident set size 1000 1000 pages

It seems the kernel stores the bytes unit which can be read by
prlimit(2) again, while ulimit - using getrlimit(2) - displays
the value in kilobytes:

$ prlimit --rss=1000 --rss strace  -f -e trace=getrlimit bash -c 'ulimit 
-m'

RESOURCE DESCRIPTION   SOFT HARD UNITS
RSS  max resident set size 1000 1000 pages
getrlimit(RLIMIT_NPROC, {rlim_cur=31578, rlim_max=31578}) = 0
getrlimit(RLIMIT_RSS, {rlim_cur=1000, rlim_max=1000}) = 0
0

That means that the manpage of prlimit(2) is incorrect, isn't it?

Thank you & have a nice day,
Berny

bug#10110: tests/id/gnu-zero-uids: skipping with "not running on GNU/Hurd" on Linux

[Bernhard Voelker]

Hi,

this new tests is skipped on my OpenSuSE-11.4 system:

...
+ require_gnu_
++ uname
+ test Linux = GNU
+ skip_ 'not running on GNU/Hurd'
+ warn_ 'gnu-zero-uids: skipped test: not running on GNU/Hurd'
+ case $IFS in
+ printf '%s\n' 'gnu-zero-uids: skipped test: not running on GNU/Hurd'
gnu-zero-uids: skipped test: not running on GNU/Hurd
+ test 9 = 2
+ printf '%s\n' 'gnu-zero-uids: skipped test: not running on GNU/Hurd'
+ sed 1q
+ Exit 77

I'm confused by this message:
I do not have a GNU/Hurd system, but the test is skipped.

Shouldn't it be "skipping test: only running on GNU/Hurd"?
Or should the test run on Linux and require_gnu_ is buggy?

Have a nice day,
Berny
SKIP: id/gnu-zero-uids (exit: 77)
=

++ initial_cwd_=/home/berny/git/coreutils/tests
++ fail=0
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /home/berny/git/coreutils/tests gt-gnu-zero-uids.
+++ case $# in
+++ destdir_=/home/berny/git/coreutils/tests
+++ template_=gt-gnu-zero-uids.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ case $template_ in
 unset TMPDIR
 mktemp -d -t -p /home/berny/git/coreutils/tests gt-gnu-zero-uids.
+++ d=/home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
+++ case $d in
+++ test -d /home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
 ls -dgo /home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
 tr S -
+++ perms='drwx-- 2 4096 Nov 22 19:48 /home/berny/git/coreutils/tests/gt-gnu-zero-uids.fti-'
+++ case $perms in
+++ test 0 = 0
+++ echo /home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
+++ return
++ test_dir_=/home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
++ cd /home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
++ gl_init_sh_nl_='
'
++ IFS=' 	
'
++ for sig_ in 1 2 3 13 15
+++ expr 1 + 128
++ eval 'trap '\''Exit 129'\'' 1'
+++ trap 'Exit 129' 1
++ for sig_ in 1 2 3 13 15
+++ expr 2 + 128
++ eval 'trap '\''Exit 130'\'' 2'
+++ trap 'Exit 130' 2
++ for sig_ in 1 2 3 13 15
+++ expr 3 + 128
++ eval 'trap '\''Exit 131'\'' 3'
+++ trap 'Exit 131' 3
++ for sig_ in 1 2 3 13 15
+++ expr 13 + 128
++ eval 'trap '\''Exit 141'\'' 13'
+++ trap 'Exit 141' 13
++ for sig_ in 1 2 3 13 15
+++ expr 15 + 128
++ eval 'trap '\''Exit 143'\'' 15'
+++ trap 'Exit 143' 15
++ trap remove_tmp_ 0
+ path_prepend_ ../src
+ test 1 '!=' 0
+ path_dir_=../src
+ case $path_dir_ in
++ cd /home/berny/git/coreutils/tests/../src
++ echo /home/berny/git/coreutils/src
+ abs_path_dir_=/home/berny/git/coreutils/src
+ case $abs_path_dir_ in
+ PATH=/home/berny/git/coreutils/src:/home/berny/git/coreutils/src:/usr/lib64/mpi/gcc/openmpi/bin:/home/berny/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games
+ create_exe_shims_ /home/berny/git/coreutils/src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ id
+ test yes = yes
+ local i
+ for i in '$*'
+ env id --version
id (GNU coreutils) 8.14.69-33314
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Arnold Robbins and David MacKenzie.
+ require_gnu_
++ uname
+ test Linux = GNU
+ skip_ 'not running on GNU/Hurd'
+ warn_ 'gnu-zero-uids: skipped test: not running on GNU/Hurd'
+ case $IFS in
+ printf '%s\n' 'gnu-zero-uids: skipped test: not running on GNU/Hurd'
gnu-zero-uids: skipped test: not running on GNU/Hurd
+ test 9 = 2
+ printf '%s\n' 'gnu-zero-uids: skipped test: not running on GNU/Hurd'
+ sed 1q
+ Exit 77
+ set +e
+ exit 77
+ exit 77
+ remove_tmp_
+ __st=77
+ cleanup_
+ :
+ cd /home/berny/git/coreutils/tests
+ chmod -R u+rwx /home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
+ rm -rf /home/berny/git/coreutils/tests/gt-gnu-zero-uids.ftiS
+ exit 77

bug#10545: make check failures on virtual machine at hoster 1und1.de

[Bernhard Voelker]

Running `make check` on a virtual machine at 1und1.de is
failing for 5 tests:

FAIL: misc/nproc-avail

++ nproc --all
+ all=4
++ OMP_NUM_THREADS=
++ nproc
+ available=8
+ test 8 -le 4
+ fail=1

I added an strace for both runs.


FAIL: tail-2/wait

+ test '!' -r unreadable
+ timeout 1 tail -s0.1 -F ---disable-inotify unreadable
tail: cannot open `unreadable' for reading: Permission denied
+ test 124 = 124
+ timeout 1 tail -s0.1 -F ---disable-inotify not_here
tail: cannot open `not_here' for reading: No such file or directory
+ test 124 = 124
+ grep -Ev 'inotify (resources exhausted|cannot be used)' tail.err
+ mv x tail.err
+ test -s tail.err
+ fail=1

Do you need an strace output here?


FAIL: ls/stat-dtype

...
+ ls --file-type d
ls: cannot access d/s: Permission denied

I added an strace log.
The same test succeeds if run as root.



FAIL: ls/stat-free-color

+ n_stat=7
+ case $n_stat in
+ fail=1


FAIL: tail-2/follow-stdin

+ timeout 1 tail -f
+ test 124 = 124
+ test -s err
+ fail=1


Server: openSUSE 11.3 (x86_64)

$ gcc --version
gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]
...


$ mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime)
$ uname -srvmpio
Linux 2.6.18-028stab094.3 #1 SMP Thu Sep 22 12:47:37 MSD 2011 x86_64 x86_64 
x86_64 GNU/Linux


Unfortunately, I don't know what virtualisation software they
are using, but as it is a mass hoster, I guess they have their own
kernel patches etc.

Some resource limits of the VM are rather low, but I don't think
the test hit any of them.

Have a nice day,
Berny



test-suite.log.xz
Description: application/xz
execve("/home/berny/depot/coreutils-8.15/src/nproc", ["nproc"], [/* 77 vars 
*/]) = 0
brk(0)  = 0x5049000
uname({sys="Linux", node="s15374368", ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2b37f61f1000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=30592, ...}) = 0
mmap(NULL, 30592, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b37f61f2000
close(3)= 0
open("/lib64/libc.so.6", O_RDONLY)  = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\354\1\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1670495, ...}) = 0
mmap(NULL, 3537800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x2b37f63f3000
fadvise64(3, 0, 3537800, POSIX_FADV_WILLNEED) = 0
mprotect(0x2b37f654a000, 2093056, PROT_NONE) = 0
mmap(0x2b37f6749000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x156000) = 0x2b37f6749000
mmap(0x2b37f674e000, 19336, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b37f674e000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2b37f6753000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2b37f6754000
arch_prctl(ARCH_SET_FS, 0x2b37f6753b20) = 0
mprotect(0x2b37f6749000, 16384, PROT_READ) = 0
mprotect(0x606000, 4096, PROT_READ) = 0
mprotect(0x2b37f63f, 4096, PROT_READ) = 0
munmap(0x2b37f61f2000, 30592)   = 0
brk(0)  = 0x5049000
brk(0x506a000)  = 0x506a000
sched_getaffinity(0, 512, {ff, 0, 0, 0}) = 32
fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2b37f61f2000
write(1, "8\n", 2)  = 2
close(1)= 0
munmap(0x2b37f61f2000, 4096)= 0
close(2)= 0
exit_group(0)   = ?
execve("/home/berny/depot/coreutils-8.15/src/nproc", ["nproc", "--all"], [/* 76 
vars */]) = 0
brk(0)  = 0x142f4000
uname({sys="Linux", node="s15374368", ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2abee84f9000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=30592, ...}) = 0
mmap(NULL, 30592, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2abee84fa000
close(3)= 0
open("/lib64/libc.so.6", O_RDONLY)  = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\354\1\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1670495, ...}) = 0
mmap(NULL, 3537800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x2abee86fb000
fadvise64(3, 0, 3537800, POSIX_FADV_WILLNEED) = 0
mprotect(0x2abee8852000, 2093056, PROT_NONE) = 0
mmap(0x2abee8a51000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x156000) = 0x2abee8

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

[Bernhard Voelker]

Playing around with the latest mv checkin,
I noticed another corner case:

Create a file 'f', a symlink 'l' to it, and
then a hardlink 's' to that symlink:

  $ touch f && ln -s f l && ln l s && ls -ogi
  total 0
  6444 -rw-r--r-- 1 0 Feb  1 08:52 f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

Trying to mv the hardlink over the symlink seems to succeed:

  $ ~/git/coreutils/src/mv s l

... but the name 's' was not unlinked:

  $ ls -ogi
  total 0
  6444 -rw-r--r-- 1 0 Feb  1 08:52 f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

Using the -v option looks also normal, but is a nop:

  $ ~/git/coreutils/src/mv -v s l
  ‘s’ -> ‘l’
  $ ls -ogi
  total 0
  6444 -rw-r--r-- 1 0 Feb  1 08:52 f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

The strace only shows the rename():

  stat("l", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
  lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
  lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
  rename("s", "l")= 0


I'd have expected either
a) the name 's' to be unlinked, or
b) an error message that something was wrong (well, whatever).
I'd prefer a) of course.

That behaviour didn't change at least since version 7.1
(on openSuSE-11.3), but back in the earlier days in 5.93
(SLES-10.3), 's' disappeared as expected:

  stat("l", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
  lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
  lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
  unlink("l") = 0
  rename("s", "l")= 0

Does mv now work as specified? Is this a kernel or
a coreutils (or a user) issue?

Have a nice day,
Berny

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

[Bernhard Voelker]

On 02/01/2012 09:21 AM, Bernhard Voelker wrote:

>   $ touch f && ln -s f l && ln l s && ls -ogi
>   total 0
>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
> 
> Trying to mv the hardlink over the symlink seems to succeed:
> 
>   $ ~/git/coreutils/src/mv s l
> 
> ... but the name 's' was not unlinked:

...

> That behaviour didn't change at least since version 7.1
> (on openSuSE-11.3), but back in the earlier days in 5.93
> (SLES-10.3), 's' disappeared as expected:

Hmm, looks like commit
   f1d1ee91217d08527c6bf7682987339e38116268
introduced this in 2006.

Have a nice day,
Berny

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

[Bernhard Voelker]

On 02/01/2012 01:47 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> Playing around with the latest mv checkin,
>> I noticed another corner case:
>>
>> Create a file 'f', a symlink 'l' to it, and
>> then a hardlink 's' to that symlink:
>>
>>   $ touch f && ln -s f l && ln l s && ls -ogi
>>   total 0
>>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
> 
> Hi Bernhard,
> Thanks for the report.
> 
> Here, you've already gotten into questionable territory, since the
> idea of a hard link to a symbolic link is not standardized.
> For example, on FreeBSD 9.0, you cannot even create one:
> (instead, it hard-links the referent of the symlink)
> 
> freebsd$ touch f && ln -s f l && ln l s && ls -ogi f l s
> 1587047 -rw-r--r-- 2 0 Feb  1 04:58 f
> 1587100 lrwxr-xr-x 1 1 Feb  1 04:58 l -> f
> 1587047 -rw-r--r-- 2 0 Feb  1 04:58 s
> 
>> Trying to mv the hardlink over the symlink seems to succeed:
>>
>>   $ ~/git/coreutils/src/mv s l
>>
>> ... but the name 's' was not unlinked:
> 
> That is definitely undesirable behavior.
> For now, one possibility is to make "mv" reject
> that corner case with this diagnostic:
> 
> mv: 's' and 'l' are the same file
> 
> Proposed patch below.
> 
>>   $ ls -ogi
>>   total 0
>>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
>>
>> Using the -v option looks also normal, but is a nop:
>>
>>   $ ~/git/coreutils/src/mv -v s l
>>   ‘s’ -> ‘l’
>>   $ ls -ogi
>>   total 0
>>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
>>
>> The strace only shows the rename():
>>
>>   stat("l", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>>   lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
>>   lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
>>   rename("s", "l")= 0
>>
>>
>> I'd have expected either
>> a) the name 's' to be unlinked, or
>> b) an error message that something was wrong (well, whatever).
>> I'd prefer a) of course.
> 
> So would I.
> 
>> That behaviour didn't change at least since version 7.1
>> (on openSuSE-11.3), but back in the earlier days in 5.93
>> (SLES-10.3), 's' disappeared as expected:
>>
>>   stat("l", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
>>   lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
>>   lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
>>   unlink("l") = 0
>>   rename("s", "l")= 0
>>
>> Does mv now work as specified? Is this a kernel or
>> a coreutils (or a user) issue?
> 
> It's a standards and kernel issue.
> POSIX explicitly says (of rename)
> 
> If the old argument and the new argument resolve to the same existing
> file, rename( ) shall return successfully and perform no other action.
> 
> though that particular wording might be slated to change with POSIX 2008,
> to allow different (more desirable) behavior.  Search the austin-group
> archives if you need to be sure.
> 
> Also, I don't know whether the above wording applies to this particular
> case of two hard links to the same symlink.  Again, I think we're in
> unspecified territory.
> 
> Here's a proposed patch.
> This is such an improbable corner case that I think it's not worth trying
> to fix any other way (either by unlinking the destination or by
> replacing rename).
> 
> (of course, if I go with this, I'll insert a big comment justifying
> this tiny change)
> 
> diff --git a/src/copy.c b/src/copy.c
> index 4810de8..78cd8c8 100644
> --- a/src/copy.c
> +++ b/src/copy.c
> @@ -1229,7 +1229,7 @@ same_file_ok (char const *src_name, struct stat const 
> *src_sb,
>   know this here IFF preserving symlinks), then it's ok -- as long
>   as they are distinct.  */
>if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode))
> -return ! same_name (src_name, dst_name);
> +return ! same_name (src_name, dst_name) && ! same_link;
> 
>src_sb_link = src_sb;
>dst_sb_link = dst_sb;

Hi Jim,

well, if it's not standardized (yet), then I agree with you that we
should choose the simpler b) alternative.

Do you think it's work thinking about the -f case?

  $ ~/git/coreutils/src/mv -f s l
  /home/berny/git/coreutils/src/mv: ‘s’ and ‘l’ are the same file

The info pages are not quite clear in which cases mv tries to
overwrite the destination. Usually, I am tempted to think that
a "--force" will "just do it" - regardless of data loss.
But in this case, mv "just does not" and the only thing left
is to rm that hardlink.

That makes me think that the implementation of the a) alternative
just reduces to calling unlink() ... ;-)

Have a nice day,
Berny

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

[Bernhard Voelker]

On 02/01/2012 03:02 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
> ...
>> well, if it's not standardized (yet), then I agree with you that we
>> should choose the simpler b) alternative.
>>
>> Do you think it's work thinking about the -f case?
>>
>>   $ ~/git/coreutils/src/mv -f s l
>>   /home/berny/git/coreutils/src/mv: ‘s’ and ‘l’ are the same file
> 
> mv's -f option is unrelated to this case.
> It relates solely to controlling whether one is prompted
> due to permissions or -i.
> 
> From 'info mv's description of the common case (no options):
> 
>If a destination file exists but is normally unwritable, standard
> input is a terminal, and the `-f' or `--force' option is not given,
> `mv' prompts the user for whether to replace the file.  (You might own
> the file, or have write permission on its directory.)  If the response
> is not affirmative, the file is skipped.
> 
> 
> Yes, it is unfortunate that the standards-imposed semantics
> of -f is different from what we'd expect.
> 

> If the above is still not clear, please suggest how to improve it.

Well, if permissions are the only case when mv would require
confirmation or -f, then it should be added to mv's description.

Additionally, the info page might also have note in which cases
mv will refuse to work, e.g. when "‘s’ and ‘l’ are the same file".

As I'm not sure (anymore) about both, I cannot propose a wording.


>> That makes me think that the implementation of the a) alternative
>> just reduces to calling unlink() ... ;-)

This hardlink-to-softlink case is IMHO identical to the normal
hardlinks case (in which mv just unlinks the source):

  $ touch f1 && ln f1 f2 && ls -ogi f1 f2
  6590 -rw-r--r-- 2 0 Feb  1 15:17 f1
  6590 -rw-r--r-- 2 0 Feb  1 15:17 f2
  $ ~/git/coreutils/src/mv f1 f2
  $ ls -ogi f1 f2
  ls: cannot access f1: No such file or directory
  6590 -rw-r--r-- 1 0 Feb  1 15:17 f2

Therefore, I'd tend to a) again. It doesn't matter if src is
a regular file or a symlink. What do you think?

Have a nice day,
Berny

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

[Bernhard Voelker]

On 02/01/2012 04:45 PM, Jim Meyering wrote:
> Thanks for the clarification and quotes, Eric.
> 
> Bernhard, here's a better patch.
> With it, mv simply unlinks the "s" in your example:
> 
> diff --git a/src/copy.c b/src/copy.c
> index 4810de8..73f5cc5 100644
> --- a/src/copy.c
> +++ b/src/copy.c
> @@ -1229,7 +1229,17 @@ same_file_ok (char const *src_name, struct stat const 
> *src_sb,
>   know this here IFF preserving symlinks), then it's ok -- as long
>   as they are distinct.  */
>if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode))
> -return ! same_name (src_name, dst_name);
> +{
> +  bool sn = same_name (src_name, dst_name);
> +  if ( ! sn && same_link)
> +{
> +  *unlink_src = true;
> +  *return_now = true;
> +  return true;
> +}
> +
> +  return ! sn;
> +}
> 
>src_sb_link = src_sb;
>dst_sb_link = dst_sb;

Thank you both.
The patch works.

I wonder if just removing the x->hard_link constraint at the beginning
of same_file_ok() would alsoo do (although the comment sounds like this
is no good idea):

@@ -1213,11 +1213,11 @@ same_file_ok (char const *src_name, struct stat const 
*src_sb,
   /* FIXME: this should (at the very least) be moved into the following
  if-block.  More likely, it should be removed, because it inhibits
  making backups.  But removing it will result in a change in behavior
  that will probably have to be documented -- and tests will have to
  be updated.  */
-  if (same && x->hard_link)
+  if (same)
 {
   *return_now = true;
   return true;
 }

Please don't think I just want to give you more work,
but I think this deserves a new test, doesn't it?

Have a nice day,
Berny

bug#11816: sort -o: error comes late if opening the outfile fails

[Bernhard Voelker]

If opening the output file for writing is not possible - e.g. because the user
doesn't have sufficient privileges, then sort issues an error. The problem
is that the whole - then useless - computation is already done.

In the following little example, it took ~15s to sort the data,
and then to realize that it can't write the result:

  $ time seq 100 | src/sort --random-sort -o /cantwritehere
  src/sort: open failed: /cantwritehere: Permission denied

  real0m14.955s
  user0m14.936s
  sys 0m0.042s

I'd have expected sort to give the error immediately after startup
instead of wasting time for sorting.
Shouldn't sort open the outfile right at the beginning (unless in==out),
or is this behavior required by some standard?

Have a nice day,
Berny

bug#11809: document "So how do we just simply make a backup file?"

[Bernhard Voelker]

On 06/29/2012 10:48 AM, Jim Meyering wrote:
> Here's the doc patch I suggested, but I'll hold off for now.
> I'd like to hear if anyone thinks it's worth adding a new option,
> which would obviate such a script.

I think it's okay, that special backup case is described in the info
page of cp twice anyway.

> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> index 08ef2d8..5207c44 100644
> --- a/doc/coreutils.texi
> +++ b/doc/coreutils.texi
> @@ -7675,9 +7675,11 @@ cp invocation
>  #!/bin/sh
>  # Usage: backup FILE...
>  # Create a @sc{gnu}-style backup of each listed FILE.
> +fail=0
>  for i; do
> -  cp --backup --force -- "$i" "$i"
> +  cp --backup --force -- "$i" "$i" || fail=1
>  done
> +exit $fail
>  @end example
> 
>  @item --copy-contents

When we speak of "backup", then maybe "--preserve=all" would be nice.

BTW: that special backup case accepts -a which includes both -d and -R
which both are maybe not ideal if you speak about a backup of a regular
file. The former treats symlinks specially, and the latter is designed
to recurse into directories - both may be misleading (although -d may
make some sense in certain situation when creating a backup of a
symlink). WDYT?

Have a nice day,
Berny

bug#11854: make syntax-check -j issue

[Bernhard Voelker]

After pulling to the lastest revision (v8.17-37-g74427c7) and
a successful build (make -j), a subsequent "make syntax-check -j"
failed:

  ...
  8.47 vulnerable_makefile_CVE-2009-4029
  8.78 copyright_check
CC hostname.o
CCLD   arch
CCLD   arch
CC hostname.o
CC hostname.o
CCLD   arch
  13.02 tight_scope
  15.36 THANKS_in_duplicates
  15.91 po_check
  mv: cannot move `.deps/hostname.Tpo' to `.deps/hostname.Po': No such file or 
directory
  make[1]: *** [hostname.o] Error 1
  make: *** [sc_check-AUTHORS] Error 2
  make: *** Waiting for unfinished jobs
  mv: cannot stat `.deps/hostname.Tpo': No such file or directory
CCLD   hostname
  make[1]: *** [hostname.o] Error 1
  make: *** [sc_man_file_correlation] Error 2

Another "make syntax-check -j" succeeded, i.e. there's some dependency
which is not taken care of for parallel syntax-check'ing.

I don't know CU's config scripts enough to know where to look at.
Any idea?

Have a nice day,
Berny

bug#11858: df -m undocumented, why no df -g

[Bernhard Voelker]

On 07/04/2012 09:38 PM, Paul Eggert wrote:
> On 07/04/2012 01:11 AM, Andreas Jaeger wrote:
>> df -k and df -m both work but only df -k is mentioned as part of df --
>> help. So, the omission to document -m is IMO a bug.
> 
> I think the general idea is that -k was a mistake, but
> it's standardized, and that we don't want to have
> options -m, -g, -t, -p, -e, -z, -y for the other sizes
> (among other things -t is already taken).  -m is there
> only for BSD compatibility but we don't want to publicize
> it and we may want to take it back at some point.

Wouldn't it then be consequent to remove the long option --megabyte?
(It's sister --kilobyte has been removed by v6.9-151-g1e07a21
in 2007.)

Have a nice day,
Berny


>From 664bf8a103585915896f3be9f3a01f11ce17ddc6 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Thu, 5 Jul 2012 08:44:22 +0200
Subject: [PATCH] df: Remove long-obsolescent --megabyte option.

* src/df.c (long_options): Remove --megabyte option.
---
 src/df.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/df.c b/src/df.c
index e99fedf..8520424 100644
--- a/src/df.c
+++ b/src/df.c
@@ -178,7 +178,6 @@ static struct option const long_options[] =
   {"human-readable", no_argument, NULL, 'h'},
   {"si", no_argument, NULL, 'H'},
   {"local", no_argument, NULL, 'l'},
-  {"megabytes", no_argument, NULL, 'm'}, /* obsolescent */
   {"portability", no_argument, NULL, 'P'},
   {"print-type", no_argument, NULL, 'T'},
   {"sync", no_argument, NULL, SYNC_OPTION},
-- 
1.7.7

bug#11858: df -m undocumented, why no df -g

[Bernhard Voelker]

On 07/05/2012 02:35 PM, Jim Meyering wrote:
> However, I'm tempted to remove it directly this time, since it's been
> undocumented for a while:
> 
>   5 years in df.1 and df --help: COREUTILS-6_9-151-g1e07a21
>   11 years in coreutils.texi: FILEUTILS-4_1_4-28-gf5bf6fe
> 
> What do you think?

I agree, the option has been added to df in 1996, and declared
obsolescent in 2001, so the period since the latter is twice as
long as the active use.

And it's very easy to s/--megabytes/-BM/ ...

Have a nice day,
Berny

bug#11858: df -m undocumented, why no df -g

[Bernhard Voelker]

On 07/05/2012 05:08 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> On 07/05/2012 02:35 PM, Jim Meyering wrote:
>>> However, I'm tempted to remove it directly this time, since it's been
>>> undocumented for a while:
>>>
>>>   5 years in df.1 and df --help: COREUTILS-6_9-151-g1e07a21
>>>   11 years in coreutils.texi: FILEUTILS-4_1_4-28-gf5bf6fe
>>>
>>> What do you think?
>>
>> I agree, the option has been added to df in 1996, and declared
>> obsolescent in 2001, so the period since the latter is twice as
>> long as the active use.
>>
>> And it's very easy to s/--megabytes/-BM/ ...
> 
> More important than 2001 is the year in which we removed
> the reference from the man page and from --help: 2007

You're right. Then what about a deprecation warning and removing
the long option in 2013?

P.S. Make "syntax-check" doesn't find the offender against
sc_error_message_uppercase for the "Warning:" message when
(mount_list == NULL) in df.c

Have a nice day,
Berny


>From 750cd181cf87160b11556f92bd098ba535780ffc Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Wed, 11 Jul 2012 17:27:20 +0200
Subject: [PATCH] df: Warn if soon-to-be-removed --megabyte option is used

* src/df.c: MEGABYTES_OPTION: Add new enum and mark it to be removed
in August 2013.
* src/df.c (long_options): Use MEGABYTES_OPTION for --megabytes option.
* src/df.c (main): Add case for MEGABYTES_OPTION and issue a deprecation
warning if the long form is being used. Document the short -m option to
exist only for BSD compatibility.
---
 src/df.c |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/df.c b/src/df.c
index e99fedf..7e30d57 100644
--- a/src/df.c
+++ b/src/df.c
@@ -167,7 +167,8 @@ static size_t nrows;
 enum
 {
   NO_SYNC_OPTION = CHAR_MAX + 1,
-  SYNC_OPTION
+  SYNC_OPTION,
+  MEGABYTES_OPTION  /* FIXME: remove long opt in Aug 2013 */
 };

 static struct option const long_options[] =
@@ -178,7 +179,7 @@ static struct option const long_options[] =
   {"human-readable", no_argument, NULL, 'h'},
   {"si", no_argument, NULL, 'H'},
   {"local", no_argument, NULL, 'l'},
-  {"megabytes", no_argument, NULL, 'm'}, /* obsolescent */
+  {"megabytes", no_argument, NULL, MEGABYTES_OPTION}, /* obsolescent,  */
   {"portability", no_argument, NULL, 'P'},
   {"print-type", no_argument, NULL, 'T'},
   {"sync", no_argument, NULL, SYNC_OPTION},
@@ -951,7 +952,14 @@ main (int argc, char **argv)
 case 'l':
   show_local_fs = true;
   break;
-case 'm': /* obsolescent */
+case MEGABYTES_OPTION:
+  /* Distinguish between the long and the short option.
+ As we want to remove the long option soon,
+ give a warning when the long form is used.  */
+  error (0, 0, "%s%s", _("warning: "),
+_("long option '--megabytes' is deprecated"
+  " and will soon be removed"));
+case 'm': /* obsolescent, exists for BSD compatibility */
   human_output_opts = 0;
   output_block_size = 1024 * 1024;
   break;
-- 
1.7.7

bug#11956: misc/tty-eof: sometimes failure under heavy load

[Bernhard Voelker]

FAIL: misc/tty-eof (exit: 1)


F: 1: YSBiCg==
F: 1: a b
F: 1: 780509149 4
F: 1: a b
F: 1: a b
F: 1: a b
F: 1: a b
F: 1: a b
F: 1: 7557d2f3a6ad1a3a8ebd23a94ab0c642  -
F: 1:  1a b
F: 1: 000 020141 005142
F: 1: a b
F: 1:
F: 1:a b
F: 1: 90ce62edf2fe4940e041a68b13e7b5f9d02bbf51  -
F: 1: afa36e61f94d23fa2869cc1ca3c7a0855ecb7f3d3305e446e7566d1f  -
F: 1: 01186fcf04b4b447f393e552964c08c7b419c1ad7a25c342a0b631b1967d3a27  -
F: 1: 
adf433b1ea7db8dec7ca64f88f4c8bc5403a1ac1d3540ae0229c79fc8d84e3db4dd9616605c61215ee7c50da0a97d0e2
  -
F: 1:
ae206702ea661de518d6451ee5b76fe0120429239b73838301991a294bc2628c0b9bbe79d06b1ab0610a66e9ce7d7e16cdcbdc244058befefc03c5d9cce54357
 -
F: 1: a b
tty-eof: sort didn't produce expected output
F: 1: 08271 1
tty-eof: tac didn't produce expected output
F: 1: a b
F: 1: a b
F: 1: a
F: 1: a b
F: 1: a b
F: 1:   1   2   4

I was running "make check-very-expensive -j 10 -l 4", and as misc/tty-eof
is quite at the top, "make" maybe didn't have a chance to balance to load
4 yet. It happens only under heavy load (CPU and disk), but I can not
reproduce it under "normal" conditions. However, with "-j 10 -l 4",
I hit it quite regularly (1 out of 4 times).

And sometimes, the "tac" error message is not there, only the "sort" error
is there.

Any idea what is going on?

Have a nice day,
Berny

bug#10915: 8.13: df -- overly long output lines are very hard to read

[Bernhard Voelker]

On 07/26/2012 04:23 PM, Pádraig Brady wrote:
> On 03/01/2012 10:56 AM, Voelker, Bernhard wrote:
>>
>> What about a more general --fmt (or --format) option to
>> just get the columns you want in the order you want?
>> E.g.
>>
>>   df --format=size,free%,mnt,fs
>> or
>>   df --format=size-h,mnt  # -h or 
>>   df --format=Size,mnt# uppercase Size meaning -h
> 
> This is a border line feature, but I'm 60:40 for implementing it.
> 
> Note something similar I noticed is:
> 
>   findmnt -l -o FSTYPE,SOURCE,TARGET
> 
> It would make sense to align as closely to that as possible.
> So a full --output list supported by df could be
> FSTYPE,SOURCE,TARGET,SIZE,USED,AVAIL,FREEPCT
> 
> It's probably sufficient to use this to just order fields,
> and leave other formatting to existing modifiers.

Implementing --output= is of course much simpler
than what Jim proposed [1]:
he suggested a stat-like --format option which takes %-directives.

That would be much more flexible for the user, and the existing
output formats would just be a pre-defined format strings.

We could for the first time have blocks and inodes statistics
in one command:

  %i  inodes
  %I  inodes in percent
  %a  AVAIL
  %A  AVAIL in percent
  %u  unused
  %U  unused percentage
  %t  total size
  %T  FSTYPE
  %s  SOURCE
  %m  TARGET (mount point)
  ...

  df --format="%u:%i:%T:%m"

And some directives could have mixed SIZE modifiers, e.g.

  %{SIZE}u  used blocks with SIZE like KMGTPEZY.
  %{SIZE}i  inode number

  df --format="%Tt %Gu %Ki %m"

Scripts could parse the output of --format (or --printf) much
safer (SOURCE and TARGET can include almost any characters like
'\n', '\t', etc. but never e.g. NULL)

  df --printf="%U\0%s\0%m\0\n"

As already said, this would be a greater change in df.c,
but some code could surely be shared with stat.c and maybe
in future with "ls --format=..." ;-)

I'm not against --output, but the advantage of a more
flexible --printf is unbeatable IMO.

Have a nice day,
Berny

[1] http://lists.gnu.org/archive/html/bug-coreutils/2012-03/msg7.html

bug#10915: 8.13: df -- overly long output lines are very hard to read

[Bernhard Voelker]

On 07/26/2012 06:11 PM, Pádraig Brady wrote:
> On 07/26/2012 04:43 PM, Bernhard Voelker wrote:
>> On 07/26/2012 04:23 PM, Pádraig Brady wrote:

>>> So a full --output list supported by df could be
>>> FSTYPE,SOURCE,TARGET,SIZE,USED,AVAIL,FREEPCT

Today, there's no FREEPCT, but USEDPCT.
I'd leave that.


> Oh right the last 4 items above should also have I... variants
> to cater for inodes.

What about ISIZE, IUSED, IAVAIL and IUSEDPCT?


>> We could for the first time have blocks and inodes statistics
>> in one command:
> 
> Good point, but that could be allowed too with --output

Right.

>> And some directives could have mixed SIZE modifiers, e.g.
>>
>>   %{SIZE}u   used blocks with SIZE like KMGTPEZY.
>>   %{SIZE}i  inode number
>>
>>   df --format="%Tt %Gu %Ki %m"
> 
> T overlaps, but I see what you mean.

The SIZE could be in {}, e.g. "%{T}t".

How could we do this with --ouput?
Maybe something like:

  df --output=SIZE/M,IFREE/K,USED/1024,TARGET

> Would you still want to apply mbsalign to all fields
> but the last when using a specific format like this?

No, the idea was to create format specifiers for that like
e.g. "%-FIELD" (left-aligned) and "%+FIELD" (right-aligned),
and to have the traditional formats be a certain combination
of it.

This would need a lot of checking ... e.g. if a format string
contained a '+' or a '-', then what should happen with the
other fields? Error? Default alignment per field? Centered?
... --format is more flexible and much more complex.

> 60:40 for --output as ordering/selection is needed by some
> 40:60 against --printf as detailed formatting is neede by few

You see, I'm still jumping between --output and --format, now
also 60:40 pro --output.

What do the others think?

Have a nice day,
Berny

bug#10915: 8.13: df -- overly long output lines are very hard to read

[Bernhard Voelker]

On 07/27/2012 02:04 PM, Jim Meyering wrote:
> However, it is hard to judge without seeing the actual changes.
> If you feel strongly about it, go ahead and implement your preference.
> Maybe the resulting code will be small and clean enough that the added
> flexibility will be an obvious net gain.

I'll try ... but it will take some time.
Thanks.

Have a nice day,
Berny

bug#9780: sort -u throws out non-duplicates

[Bernhard Voelker]

On 08/16/2012 10:09 AM, Jim Meyering wrote:
>> FYI, here's the required test:
>> >
>> >   (yes 7|head -10; echo 1)|sed 's/^/1 /'|sort -k2,2 --p=1 -S32b -u
>> >
>> > Without the if (key) { ... } part of my patch, it would fail.
>> > I had to tweak the number of '7's (s/11/10) in the input to make
>> > it trigger.
> Hmm... The above is arch-specific.
> It triggers the bug on i686, but not on x86_64.

This triggers the bug on my x86_64:

  $ ~/cu> (yes 7|head -n 100; echo 1)|sed 's/^/1 /'| src/sort -k2,2 --p=1 -S1k 
-u
  1 7

However, a little different line does not:

  $ ~/cu> (yes 7|head -n 10; echo 1)|sed 's/^/1 /'| src/sort -k2,2 --p=1 -S1k -u
  1 1
  1 7

  $ ~/cu> (yes 7|head -n 100; echo 1)|sed 's/^/1 /'| src/sort -k2,2 --p=1 -S1M 
-u
  1 1
  1 7

Have a ncie day,
Berny

bug#12212: [patch] dd's help text contains superfluous word

[Bernhard Voelker]

Re: [PATCH 1/2] dd: the word BLOCKS no longer occurs in the help text

On 08/16/2012 06:45 PM, Benno Schulenberg wrote:
> 
> Hi,
> 
> The help text of dd now mentions that the word BLOCKS can
> be replaced with something.  But the word BLOCKS does not
> occur any longer in the entire help text.  Attached patch
> removes the superfluous mention.

argh, that renaming from BLOCKS to N was done in v8.15-38-g140eca1,
and I added the documentation for N again in v8.17-26-g4f2e9d5
without noticing that. Sorry for that.

BLOCKS is still mentioned in coreutils.texi.
Here's the fix:

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 62b31fe..265d2e5 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8402,7 +8402,7 @@ affected file descriptors, even after @command{dd} exits.
 @end table

 @cindex multipliers after numbers
-The numeric-valued strings above (@var{n}, @var{bytes} and @var{blocks})
+The numeric-valued strings above (@var{n} and @var{bytes})
 can be followed by a multiplier: @samp{b}=512, @samp{c}=1,
 @samp{w}=2, @samp{x@var{m}}=@var{m}, or any of the
 standard block size suffixes like @samp{k}=1024 (@pxref{Block size}).


Have a nice day,
Berny

bug#9780: sort -u data loss deserves new release ASAP [Re: bug#9780: sort -u...

[Bernhard Voelker]

On 08/17/2012 12:00 PM, Jim Meyering wrote:
> I want to make a release with this fix as soon as possible.
> Since I'm making this a mostly-bug-fix release, the du and md5 --tag
> changes will have to wait for 8.20.
> However, I'll be happy to apply documentation-correcting changes
> if someone would post a complete, updated patch or two.
> 
> If Bruce and Paul find that changing gnulib's parse-datetime test
> will avoid a failure on LFS, I'll pull in a gnulib update for that.
> 
> Any other bug-fix-like changes that people can suggest?

Hi Jim,

the first part of Benno's patch is a trivial documentation fix:
  http://debbugs.gnu.org/12212
  [PATCH 1/2] dd: the word BLOCKS no longer occurs in the help text

It fixes the man-page of dd. I replied that the same is
necessary in coreutils.texi, but there's no commitable patch
yet.

Now I see that you already CC'ed Benno ...

Have a nice day,
Berny

bug#12301: tail -F & ZFS

[Bernhard Voelker]

On 08/29/2012 09:43 AM, Jim Meyering wrote:
> This change enables tail -f to use inotify and lets
> stat -f --format=%T report the file system type name, "zfs".
> * src/stat.c (human_fstype): Add a case: zfs, 0x2fc12fc1.

Hi Jim,

I tried to find documentation about that magic number.

There seem to exist several implementations of ZFS [1],
and I could find it only for the ZFSONLINUX project [2],
but not in the official OpenSolaris ZFS specification [3].

Can we be sure that 0x2fc12fc1 is used for all ZFS
implementations?

[1] http://en.wikipedia.org/wiki/ZFS
[2] https://github.com/zfsonlinux/zfs/blob/master/include/sys/zfs_vfsops.h
[3] 
http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf

Have a nice day,
Berny

bug#12301: tail -F & ZFS

[Bernhard Voelker]

On 08/29/2012 11:12 AM, Jim Meyering wrote:
>> Can we be sure that 0x2fc12fc1 is used for all ZFS
>> implementations?
>
> If there end up being two or more magic numbers for the same file
> system (or ZFS variants going by new names), we'll adapt.

Ok, that sounds good. Thanks.

Have a nice day,
Berny

bug#12322: coreutils-8.1{8, 9} with /etc/mtab as real file, df/total-unprocessed fail, df/no-mtab-status is skipped

[Bernhard Voelker]

On 09/01/2012 05:49 PM, g@free.fr wrote:
> Maybe both tests could check if /etc/mtab is a symlink and adjust df 
> parameter to not fail?
> 
> I made this change on the tests to see if that work
>   cd $(DIR_APP) && sed -i "s/ '\.' / /" tests/df/total-unprocessed
>   cd $(DIR_APP) && sed -i "s/df ||/df '.' ||/" tests/df/no-mtab-status
> 
> With /etc/mtab as a real file, both tests passed

Thank you for the report.

To make it clear, your change suggests this:

diff --git a/tests/df/no-mtab-status.sh b/tests/df/no-mtab-status.sh
index e434f5f..6d19f8b 100755
--- a/tests/df/no-mtab-status.sh
+++ b/tests/df/no-mtab-status.sh
@@ -20,7 +20,7 @@
 . "${srcdir=.}/init.sh"; path_prepend_ ../src
 print_ver_ df

-df || skip_ "df fails"
+df '.' || skip_ "df fails"

 # Simulate "mtab" failure.
 cat > k.c <<'EOF' || framework_failure_
diff --git a/tests/df/total-unprocessed.sh b/tests/df/total-unprocessed.sh
index aa49836..dbe552e5 100755
--- a/tests/df/total-unprocessed.sh
+++ b/tests/df/total-unprocessed.sh
@@ -28,7 +28,7 @@ EOF
 # The following simply finds no match for the combination
 # of the options --local and FS-type nfs together with the
 # argument ".". It must exit non-Zero nonetheless.
-df --local -t nfs --total '.' 2>out && fail=1
+df --local -t nfs --total 2>out && fail=1
 compare exp out || fail=1

 cat <<\EOF > exp || framework_failure_


Additionally to a missing mtab, there is another reason which
can make df fail: an inaccessible mount point, e.g. when there's
a file system mounted on /root/backup which is not accessible
by a normal user.

The above tests provoke certain error conditions:
no-mtab-status tests df's behaviour when the mtab cannot be read;
total-unprocessed tests that df exits non-Zero and writes an error
message when --total is used but no file system has been processed.

While your change doesn't make the tests skip under certain
conditions, it well may trigger a different than the intended
failure. E.g. in no-mtab-status, there's a test which is supposed
to fail because we simulated the mtab failure:

  # These tests are supposed to fail:
  LD_PRELOAD=./k.so df && fail=1

That command - a simple df without arguments - could also fail due
to another reason (see above), so the failure may shadow the expected
failure from (simulated) missing mtab.

That said, I'd rather skip a test that cannot otherwise guarantee
why it fails/succeeds.

Have a nice day,
Berny

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

[Bernhard Voelker]

On 09/03/2012 10:04 PM, Paul Eggert wrote:
> I was about to suggest the following, on GNU/Linux:
> 
>   # Don't do this unless you know what you're doing!
>   rm -fr /proc/self/cwd/
> 
> Except it doesn't work!  Not even if I append '.':
> 
>   $ mkdir /tmp/victim
>   $ cd /tmp/victim
>   $ touch foo
>   $ rm -fr /proc/self/cwd/
>   rm: cannot remove `/proc/self/cwd': Too many levels of symbolic links


That is in rm_fts():

  /* Perform checks that can apply only for command-line arguments.  */
  if (ent->fts_level == FTS_ROOTLEVEL)
{
  if (strip_trailing_slashes (ent->fts_path))
ent->fts_pathlen = strlen (ent->fts_path);

ent->fts_path is stripped from /proc/self/cwd/ to /proc/self/cwd.
Then this:

Ternary is_empty_directory;
enum RM_status s = prompt (fts, ent, true /*is_dir*/, x,
   PA_DESCEND_INTO_DIR, &is_empty_directory);

if (s == RM_OK && is_empty_directory == T_YES)
  {
/* When we know (from prompt when in interactive mode)
   that this is an empty directory, don't prompt twice.  */
s = excise (fts, ent, x, true);
fts_skip_tree (fts, ent);
  }

s is RM_OK, but is_empty_directory is T_NO, because it's no DIR ...
The FTS loop continues and diagnoses ELOOP. That's the strace output:

  newfstatat(AT_FDCWD, "/proc/self/cwd/", {st_mode=S_IFDIR|0755, st_size=4096, 
...}, AT_SYMLINK_NOFOLLOW) = 0
  openat(AT_FDCWD, "/proc/self/cwd", 
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 ELOOP (Too many 
levels of
symbolic links)
  openat(AT_FDCWD, "/proc/self/cwd", 
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 ELOOP (Too many 
levels of
symbolic links)
  unlinkat(AT_FDCWD, "/proc/self/cwd", AT_REMOVEDIR) = -1 EACCES (Permission 
denied)

The example applies to all symlinks to directories (i.e. not only
to /proc/self/cwd):

  $ mkdir d
  $ touch d/file
  $ ln -s d dl
  $ rm -rv dl/
  /home/berny/cu/src/rm: cannot remove ‘dl’: Too many levels of symbolic links

However, in this case, unlinkat returns ENOTDIR:

  unlinkat(AT_FDCWD, "dl", AT_REMOVEDIR)  = -1 ENOTDIR (Not a directory)



>   $ rm -fr /proc/self/cwd/.
>   rm: cannot remove directory: `/proc/self/cwd/.'
>   $ ls
>   foo

That's the dot case.

> Aren't these bugs, at least?

The latter: no, because dot must not be removed.
The former: maybe, but the question is what rm should remove:
the symlink or the target? The info page is quiet about this.
I tend to say it's okay as it is, because if someone wants to
remove the target of a symlink,(s)he can always to
  $ rm -rv $(readlink -f dl)
Only the diagnostic (ELOOP) looks a bit strange ...

Have a nice day,
Berny

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

[Bernhard Voelker]

On 09/04/2012 12:42 PM, Jim Meyering wrote:
> I have mixed feelings, but am leaning towards the
> Solaris 11/FreeBSD behavior.

They must have fixed it for Solaris, here's an older one:

  $ uname -sr ; mkdir d; ln -s d s; /bin/rm -r s/; ls
  SunOS 5.9
  d

Have a nice day,
Berny

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

[Bernhard Voelker]

On 09/04/2012 02:55 PM, Jim Meyering wrote:
> With the following patch, I see new behavior.
> It's an improvement, but we're still not there:
> 
> $ mkdir -p d/e/f; ln -s d s; rm -r s/
> rm: cannot remove 's/': Not a directory
> [Exit 1]
> $ find
> .
> ./s
> ./d
> 
> Notice how it did traverse s/ into d/, and removed d/e and d/e/f.
> The only problem is that when it attempted to remove the command-line
> specified "s/", unlinkat (AT_FDCWD, "s/", AT_REMOVEDIR) failed:
> 
> unlinkat(4, "d", 0) = 0
> unlinkat(5, "f", AT_REMOVEDIR)  = 0
> unlinkat(4, "e", AT_REMOVEDIR)  = 0
> unlinkat(AT_FDCWD, "s/", AT_REMOVEDIR)  = -1 ENOTDIR (Not a directory)
> rm: cannot remove 's/': Not a directory
> +++ exited with 1 +++
> 
> Now, this looks like a problem with unlinkat.

Hmm, what about dereferencing command line symlinks with trailing
slashes _before_ entering the FTS loop instead?

Have a nice day,
Berny

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

[Bernhard Voelker]

On 09/04/2012 04:46 PM, Jim Meyering wrote:
> incvolving 3 or more prime factors.)  When s = 2, we get the 3/4 factor.

s/incvolving/involving/

Have a nice day,
Berny

bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir

[Bernhard Voelker]

On 09/05/2012 08:25 AM, Paul Eggert wrote:
> On 09/04/2012 06:55 PM, Linda A. Walsh wrote:
>  
>> So how do delete all files in the directory without wild cards?
>
> Why tie your hands behind your back?  Use wild cards:
> 
>   cd DIRECTORY && rm -fr * .[!.] .??*
> 
> If you do this a lot, put it into a shell script.
> It's not like the need is all that common, for most people,
> but if you need it that's what scripts are for.
> 
> If you fiddle with your shell settings about
> how wildcards are expanded, make
> sure your script does wildcards in the standard way.

Exactly, we're now at the point where globbing is the topic,
much way away from coreutils and rm.

Bash knows dotglob:

  $ mkdir d; cd d
  $ touch .a b ; mkdir c
  $ ( shopt -s dotglob ; rm -rv * )
  removed `.a'
  removed `b'
  removed directory: `c'

Have a nice day,
Berny

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

[Bernhard Voelker]

On September 6, 2012 at 12:56 PM Linda Walsh  wrote:

> Jim Meyering wrote:
> > Thanks for the patch, but it would be pretty rotten for GNU rm to make
> > it so "rm -rf ." deletes everything under ".", while all other vendor
> > rm programs diagnose the POSIX-mandated error.  People would curse us
> > for making GNU rm remove their precious files when they accidentally ran
> > that command.
> ---
>
> Just like people who ran "rm -fr * in /" and didn't get their POSIX
> mandated behavior, would curse you?
>
> You are playing Mommy, to people and not allowing them to do what
> they are asking the computer to do.
>
> [... and ~40 lines re. Jim, GNU, POSIX, the universe ...]

Dear Linda,

why don't you stick to the point?

You provided a patch which changes the *default behaviour* of rm,
and Jim told you that we can't/shouldn't do this.

What you want was an option to delete the content of a directory.
So why discussing all the world and his brother instead of providing
a new patch introducing such a new option (e.g. --only-dir-content,
there should be a better name)?
Generalizations like that don't help here, IMHO.

Have a nice day,
Berny

bug#12366: [gnu-prog-discuss] Writing unwritable files

[Bernhard Voelker]

On September 6, 2012 at 2:12 PM Paolo Bonzini  wrote:

> [For bug-coreutils: the context here is that sed -i, just like perl -i,
> breaks hard links and thus destroys the content of files with 0400
> permission].

I consider this being 2 different cases:

* 'sed -i' breaks hard links:
That's because it places the output at place where
the input file was (by unlink+rename).
That's okay IMO.

* 'sed -i' destroys the content of files with 0400 perms:
That's a bug IMHO. sed should open the input file read-write.
If that fails, then the input won't change with a nice diagnostic.

In 'sort -o', we recently added a similar check right at the beginning
to avoid useless processing possibly leading to an error afterwards:
see http://bugs.gnu.org/11816 with the commit
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=44fbd3fd862e34d42006f8b74cb11c9c56346417


Have a nice day,
Berny

bug#12365: Should cp -n return 0, when DEST exists?

[Bernhard Voelker]

On September 6, 2012 at 5:24 PM Jim Meyering  wrote:

> Bernhard Voelker wrote:
> > Maybe it's worth adding a line about the exist status
> > when using -n or -i (together with answering 'n')?
>
> Yes, please.  That would be an improvement.

(my first patch created on cygwin)


>From 65d2d16340cee38f0a7e059af86be49f21eef84d Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Thu, 6 Sep 2012 18:39:47 +0200
Subject: [PATCH] doc: improve documentation of -n and -i for cp and mv
* doc/coreutils.texi (cp invocation): Add a note about to the
description of the option -n how it compares to -i. Add a note
about a possible exit status zero when -n or -i is used.
(mv invocation): Likewise.
---
doc/coreutils.texi | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f2620bc..0324d1b 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7772,8 +7772,14 @@ a regular file in the destination tree.
@opindex -n
@opindex --no-clobber
Do not overwrite an existing file. The @option{-n} option overrides a previous
-@option{-i} option. This option is mutually exclusive with @option{-b} or
-@option{--backup} option.
+@option{-i} option.
+@macro optClobberAndI
+In effect, this option works as if the option @option{-i}
+was given and the user declined all questions to overwrite the targets (sure
+enough without prompting).
+@end macro
+@optClobberAndI
+This option is mutually exclusive with @option{-b} or @option{--backup} option.

@item -P
@itemx --no-dereference
@@ -8026,8 +8032,15 @@ However, mount point directories @emph{are} copied.

@end table

+@cindex exit status of @command{cp}
+Exit status:
+
@exitstatus

+However, if the existing target is not overwritten because the option
+@option{-n} is used or the option @option{-i} is used and the user has declined
+overwriting that file, then @command{cp}'s exit status is yet zero.
+

@node dd invocation
@section @command{dd}: Convert and copy a file
@@ -8747,6 +8760,7 @@ If the response is not affirmative, the file is skipped.
@cindex prompts, omitting
Do not overwrite an existing file.
@mvOptsIfn
+@optClobberAndI
This option is mutually exclusive with @option{-b} or @option{--backup} option.

@item -u
@@ -8778,8 +8792,15 @@ Print the name of each file before moving it.

@end table

+@cindex exit status of @command{mv}
+Exit status:
+
@exitstatus

+However, if the existing target is not overwritten because the option
+@option{-n} is used or the option @option{-i} is used and the user has declined
+overwriting that file, then @command{mv}'s exit status is yet zero.
+

@node rm invocation
@section @command{rm}: Remove files or directories
--
1.7.9

bug#12366: [gnu-prog-discuss] Writing unwritable files

[Bernhard Voelker]

On September 6, 2012 at 7:23 PM Paul Eggert  wrote:

> On 09/06/2012 10:12 AM, Bob Proulx wrote:
> > The file replacement is atomic.  The reading of the file is not.
>
> Sure, but the point is that from the end user's
> point of view, 'sed -i' is not atomic, and can't
> be expected to be atomic.
>
> 'sed -i' and 'sort -o' both use some atomic operations
> internally, but neither is atomic overall.  Users who
> want atomicity must look elsewhere, or implement it
> themselves.

Why can't 'sed -i' be made atomic for the user?
Today, it creates a temporary file for the output.
At the end, it calls rename(). What if it instead
rewinds the input and that temporary file and copies
it's content to the input file?
Okay, this is slower than a rename(), but it would
write into the same inode. To preserve today's behaviour,
this could be done with a new option like --in-place-same.

Just a thought.

Have a nice day,
Berny

bug#12445: ls --color does not color symlinks when not resolving them

[Bernhard Voelker]

On 09/16/2012 05:46 AM, Pádraig Brady wrote:

> +++ b/tests/misc/ls-misc.pl
> @@ -263,6 +263,21 @@ my @Tests =
>{POST => sub {unlink 's' or die "s: $!\n";
>  restore_ls_colors; }},
>   ],
> + # The code related to the above fixes introduced a regression,
> + # that was fixed after coreutils-8.19.

What did you want to say by this?

Have a nice day,
Berny

bug#12445: ls --color does not color symlinks when not resolving them

[Bernhard Voelker]

On 09/16/2012 11:03 AM, Jim Meyering wrote:
> Bernhard Voelker wrote:
> 
>> On 09/16/2012 05:46 AM, Pádraig Brady wrote:
>>
>>> + # The code related to the above fixes introduced a regression,
>>> + # that was fixed after coreutils-8.19.
>>
>> What did you want to say by this?
> 
> I understood it as:
> 
> The patch associated with the above test case introduced a
> regression, which was fixed after coreutils-8.19.

so maybe
  s/fixes introduced/introduced/
?

Have a nice day,
Berny

bug#12212: [patch] dd's help text contains superfluous word

[Bernhard Voelker]

On 08/17/2012 08:30 AM, Bernhard Voelker wrote:
> Re: [PATCH 1/2] dd: the word BLOCKS no longer occurs in the help text
> 
> On 08/16/2012 06:45 PM, Benno Schulenberg wrote:
>>
>> Hi,
>>
>> The help text of dd now mentions that the word BLOCKS can
>> be replaced with something.  But the word BLOCKS does not
>> occur any longer in the entire help text.  Attached patch
>> removes the superfluous mention.
> 
> argh, that renaming from BLOCKS to N was done in v8.15-38-g140eca1,
> and I added the documentation for N again in v8.17-26-g4f2e9d5
> without noticing that. Sorry for that.
> 
> BLOCKS is still mentioned in coreutils.texi.
> Here's the fix:
> 
> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> index 62b31fe..265d2e5 100644
> --- a/doc/coreutils.texi
> +++ b/doc/coreutils.texi
> @@ -8402,7 +8402,7 @@ affected file descriptors, even after @command{dd} 
> exits.
>  @end table
> 
>  @cindex multipliers after numbers
> -The numeric-valued strings above (@var{n}, @var{bytes} and @var{blocks})
> +The numeric-valued strings above (@var{n} and @var{bytes})
>  can be followed by a multiplier: @samp{b}=512, @samp{c}=1,
>  @samp{w}=2, @samp{x@var{m}}=@var{m}, or any of the
>  standard block size suffixes like @samp{k}=1024 (@pxref{Block size}).
> 
> 
> Have a nice day,
> Berny

Anyone catching up on Benno's patch with my addendum?
(I'm not sure about the second patch though.)

Have a nice day,
Berny

bug#12212: [patch] dd's help text contains superfluous word

[Bernhard Voelker]

On 09/18/2012 02:27 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> Anyone catching up on Benno's patch with my addendum?
>> (I'm not sure about the second patch though.)
> 
> Hi Berny,
> I was waiting for a complete patch ;-)

Hi Jim,

actually, me too ;-)
I've never written a patch in other contributors name yet.
Here's a try.

Have a nice day,
Berny


>From d2e4c4a276c096b46598c71fe8b6f63eb89adbe5 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg 
Date: Tue, 18 Sep 2012 14:50:47 +0200
Subject: [PATCH] dd: remove references to the word BLOCKS from help and texi
 docs

The renaming from BLOCKS to N was done in v8.15-38-g140eca1,
and a documentation for N was added again in v8.17-26-g4f2e9d5
without noticing that. Now, finally remove the word BLOCKS
from the documentation.

* src/dd.c (usage): Remove the word BLOCKS.
* doc/coreutils.texi (dd invocation): Likewise.

Improved by: Bernhard Voelker 
---
 doc/coreutils.texi |2 +-
 src/dd.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index cb4ad83..437ae5d 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8413,7 +8413,7 @@ affected file descriptors, even after @command{dd} exits.
 @end table

 @cindex multipliers after numbers
-The numeric-valued strings above (@var{n}, @var{bytes} and @var{blocks})
+The numeric-valued strings above (@var{n} and @var{blocks})
 can be followed by a multiplier: @samp{b}=512, @samp{c}=1,
 @samp{w}=2, @samp{x@var{m}}=@var{m}, or any of the
 standard block size suffixes like @samp{k}=1024 (@pxref{Block size}).
diff --git a/src/dd.c b/src/dd.c
index 2ebbfae..de51435 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -540,7 +540,7 @@ Copy a file, converting and formatting according to the 
operands.\n\
 "), stdout);
   fputs (_("\
 \n\
-N, BLOCKS and BYTES may be followed by the following multiplicative 
suffixes:\n\
+N and BYTES may be followed by the following multiplicative suffixes:\n\
 c =1, w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M\n\
 GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.\n\
 \n\
-- 
1.7.7

bug#12212: [patch] dd's help text contains superfluous word

[Bernhard Voelker]

On 09/18/2012 02:54 PM, Bernhard Voelker wrote:
> Here's a try.

oops, sorry. I removed the wrong word in the texi file.

Here's a better one.

>From 39ea828e94e8232660f83c62e1eff85026070b4c Mon Sep 17 00:00:00 2001
From: Benno Schulenberg 
Date: Tue, 18 Sep 2012 14:58:42 +0200
Subject: [PATCH] dd: remove references to the word BLOCKS from help and texi
 docs

The renaming from BLOCKS to N was done in v8.15-38-g140eca1,
and a documentation for N was added again in v8.17-26-g4f2e9d5
without noticing that. Now, finally remove the word BLOCKS
from the documentation.

* src/dd.c (usage): Remove the word BLOCKS.
* doc/coreutils.texi (dd invocation): Likewise.

Improved by: Bernhard Voelker 
---
 doc/coreutils.texi |2 +-
 src/dd.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index cb4ad83..c0abd7f 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8413,7 +8413,7 @@ affected file descriptors, even after @command{dd} exits.
 @end table

 @cindex multipliers after numbers
-The numeric-valued strings above (@var{n}, @var{bytes} and @var{blocks})
+The numeric-valued strings above (@var{n} and @var{bytes})
 can be followed by a multiplier: @samp{b}=512, @samp{c}=1,
 @samp{w}=2, @samp{x@var{m}}=@var{m}, or any of the
 standard block size suffixes like @samp{k}=1024 (@pxref{Block size}).
diff --git a/src/dd.c b/src/dd.c
index 2ebbfae..de51435 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -540,7 +540,7 @@ Copy a file, converting and formatting according to the 
operands.\n\
 "), stdout);
   fputs (_("\
 \n\
-N, BLOCKS and BYTES may be followed by the following multiplicative 
suffixes:\n\
+N and BYTES may be followed by the following multiplicative suffixes:\n\
 c =1, w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M\n\
 GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.\n\
 \n\
-- 
1.7.7

bug#12212: [patch] dd's help text contains superfluous word

[Bernhard Voelker]

On 09/18/2012 03:20 PM, Jim Meyering wrote:
> Applied with the above log tweaks.
> Will push shortly.

Thanks!

bug#12542: [PATCH] du: avoid abort on systems for which ->me_type is not malloc'd

[Bernhard Voelker]

On 09/30/2012 02:43 PM, Jim Meyering wrote:
> A better one should come soon, in which I add
> a function in mountlist.c (declared in the .h file)
> by which to encapsulate this mount-entry freeing process.

Good idea - also df doesn't free the mount_list:

valgrind --leak-check=full --show-reachable=yes src/df /
==3835== Memcheck, a memory error detector
==3835== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3835== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==3835== Command: src/df /
==3835==
Filesystem 1K-blocksUsed Available Use% Mounted on
/dev/sda1   12095032 7434584   4046048  65% /
==3835==
==3835== HEAP SUMMARY:
==3835== in use at exit: 3,013 bytes in 149 blocks
==3835==   total heap usage: 657 allocs, 508 frees, 41,101 bytes allocated
==3835==
==3835== 144 bytes in 1 blocks are still reachable in loss record 1 of 5
==3835==at 0x4C297CD: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3835==by 0x40A1B8: xmalloc (xmalloc.c:43)
==3835==by 0x402F90: main (xalloc.h:113)
==3835==
==3835== 254 bytes in 37 blocks are still reachable in loss record 2 of 5
==3835==at 0x4C297CD: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3835==by 0x40A1B8: xmalloc (xmalloc.c:43)
==3835==by 0x40A2CB: xmemdup (xmalloc.c:115)
==3835==by 0x40AE8E: read_file_system_list (mountlist.c:420)
==3835==by 0x4028F8: main (df.c:1097)
==3835==
==3835== 292 bytes in 37 blocks are still reachable in loss record 3 of 5
==3835==at 0x4C297CD: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3835==by 0x40A1B8: xmalloc (xmalloc.c:43)
==3835==by 0x40A2CB: xmemdup (xmalloc.c:115)
==3835==by 0x40AE75: read_file_system_list (mountlist.c:418)
==3835==by 0x4028F8: main (df.c:1097)
==3835==
==3835== 547 bytes in 37 blocks are still reachable in loss record 4 of 5
==3835==at 0x4C297CD: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3835==by 0x40A1B8: xmalloc (xmalloc.c:43)
==3835==by 0x40A2CB: xmemdup (xmalloc.c:115)
==3835==by 0x40AE81: read_file_system_list (mountlist.c:419)
==3835==by 0x4028F8: main (df.c:1097)
==3835==
==3835== 1,776 bytes in 37 blocks are still reachable in loss record 5 of 5
==3835==at 0x4C297CD: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3835==by 0x40A1B8: xmalloc (xmalloc.c:43)
==3835==by 0x40AE69: read_file_system_list (mountlist.c:417)
==3835==by 0x4028F8: main (df.c:1097)
==3835==
==3835== LEAK SUMMARY:
==3835==definitely lost: 0 bytes in 0 blocks
==3835==indirectly lost: 0 bytes in 0 blocks
==3835==  possibly lost: 0 bytes in 0 blocks
==3835==still reachable: 3,013 bytes in 149 blocks
==3835== suppressed: 0 bytes in 0 blocks
==3835==
==3835== For counts of detected and suppressed errors, rerun with: -v
==3835== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

The first one can be covered by "IF_LINT ( free (columns));",
but the others come from calling read_file_system_list().

Free()ing the memory should of course be guarded by IF_LINT, too.

Have a nice day,
Berny

bug#12656: WG: Re[4]: bug#12656: cp since 8.11 corrupts files

[Bernhard Voelker]

On 10/17/2012 10:44 AM, Jim Meyering wrote:
> From a5365003c88f4fce6293827c13f90acd0b5bd0cc Mon Sep 17 00:00:00 2001
> From: Jim Meyering 
> Date: Tue, 16 Oct 2012 17:43:49 +0200
> Subject: [PATCH] cp: avoid data-corrupting free-memory-read
> 
> * src/extent-scan.c (extent_scan_read): Reset our last_ei
> pointer whenever the parent buffer might have just been freed.
> * tests/cp/fiemap-extent-FMR.sh: New test.
> * tests/local.mk (all_tests): Add it.
> * NEWS (Bug fixes): Mention it.
> Reported by Mike Gerth in http://bugs.gnu.org/12656, and with
> help from Alan Curry.  Bug introduced in commit v8.10-60-g18f5a85.
> ---
>  NEWS   |  4 
>  src/extent-scan.c  | 12 +---
>  tests/cp/fiemap-FMR.sh | 31 +++
>  tests/local.mk |  1 +
>  4 files changed, 45 insertions(+), 3 deletions(-)
>  create mode 100755 tests/cp/fiemap-FMR.sh
> 
> diff --git a/NEWS b/NEWS
> index aff5bf1..46ce698 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -12,6 +12,10 @@ GNU coreutils NEWS-*- 
> outline -*-
> 
>  ** Bug fixes
> 
> +  cp could read from freed memory and could even make corrupt copies.
> +  This could happen only with a very fragmented input file and when using
> +  its FIEMAP/extent-based copying code.  [bug introduced in coreutils-8.11]

As the bug is in extent-scan.c, doesn't it also affect mv (and ginstall)?

In src/local.mk:

  copy_sources = \
src/copy.c \
src/cp-hash.c \
src/extent-scan.c \
src/extent-scan.h

  ...
  src_ginstall_SOURCES = src/install.c src/prog-fprintf.c $(copy_sources)
  ...
  src_cp_SOURCES = src/cp.c $(copy_sources)
  ...
  src_mv_SOURCES = src/mv.c src/remove.c $(copy_sources)



Have a nice day,
Berny

bug#12715: [PATCH] build: do not require help2man at build-from-tarball time

[Bernhard Voelker]

On 10/25/2012 04:08 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> Isn't it "Due to lack on the build system, ..."?
>>
>> I.e. coreutils could be built on system A lacking perl,
>> and then be installed on system B which has perl. The above
>> text would be misleading in this case.
> 
> Good point.
> I've merged this in:
> 
> diff --git a/man/dummy-man b/man/dummy-man
> index 633a5ba..3069376 100755
> --- a/man/dummy-man
> +++ b/man/dummy-man
> @@ -56,8 +56,8 @@ cat >"$output" <  $progname $bs- a $source program
>  .SH DESCRIPTION
>  .B OOOPS!
> -Due to lack of perl on your system, the $source build system
> -failed to create the manual page for
> +Due to the lack of perl on the build system, we were
> +unable to create a proper manual page for
>  .B $progname.
>  For concise option descriptions, run
>  .IP

Looks good, thanks.

Berny

bug#12794: Bug in dd: it sends wrong messages to stderr

[Bernhard Voelker]

Dear Linda,

On 11/07/2012 10:06 AM, Linda Walsh wrote:
> That something appears "open" to 
> contributing, means nothing by itself.

yes, it does (see below).

> I've seen more than one open 
> source projects that claimed to be "open", only to see patches to 
> correct design problems, persistently ignored for personal or political 
> reasons -- even when such flaws clearly couldn't be justified on 
> objective, sound, engineering principles.

That's the idea behind "open source" - if you don't like what a program
is doing, or when you have a special reason for the tool behaving different
in your personal, political, or even commercial environment, then take
the sources, modify them to your needs and use the changed tool. Even
spread it around if you like (with the changed sources of course ...).
Everybody knows there are other tools with other licenses where you don't
get this chance.

[hey, now I also avoid using 'you', funny.
 So let's use that *BAD* word again. ;-)  ]

The problem comes when you want to have your change in *that* package
everyone is using, e.g. coreutils. As there are *many* users, these tools
have to do the right thing for them all. And if the change would break
what many users are expecting from that tool, or even what they are used
to, then there must be very good reasons to do the change.

Going back to #12794: there were several misunderstanding in the discussion,
which IMO are all clear now: Bob referred to a mail of Padraig which
never reached Ganton. Well ... let's move on.
Re. dd's output: comparing that little glitch regarding output
behavior we are used from newer tools with the power of dd, I must say
I'm very happy how it is. And if somebody does't like that, then [s]he
is free to use the new "status=none" (unless using a non-GNU dd, of course).

Have a nice day,
Berny

bug#12841: Make for AIX 8.20 fails with undefined symbol .rpl_malloc

[Bernhard Voelker]

On 11/13/2012 06:19 AM, Paul Eggert wrote:
> I pushed the following further change, to fix it.

Something seems to be not quite correct:

  $ make clean all
  [...]
CC   src/factor.o
  src/factor.c:679:1: error: 'WIDE_UINT_BITS' undeclared here (not in a 
function)
  src/factor.c:679:1: error: expression in static assertion is not an integer

  $ head -n4 src/primes.h
  /* Generated file -- DO NOT EDIT */

  P ( 1,  26, 0xaaabUL, 0xUL) /* 3 */
  P ( 2,  26, 0xcccdUL, 0xUL) /* 5 */

  $ make src/primes.h
  make: `src/primes.h' is up to date.

  $ rm src/primes.h
  rm: remove write-protected regular file `src/primes.h'? y

  $ make src/primes.h
  make src/make-prime-list
GEN  src/primes.h

  $ head -n3 src/primes.h
  /* Generated file -- DO NOT EDIT */

  #define WIDE_UINT_BITS 128

I'm not sure, but shouldn't the prime list src/primes.h depend
on src/make-prime-list?

Furthermore, shouldn't src/primes.h be included in .gitignore?

Have a nice day,
Berny

bug#12841: Make for AIX 8.20 fails with undefined symbol .rpl_malloc

[Bernhard Voelker]

On 11/13/2012 04:46 PM, Paul Eggert wrote:
> On 11/12/2012 11:00 PM, Bernhard Voelker wrote:
>> I'm not sure, but shouldn't the prime list src/primes.h depend
>> on src/make-prime-list?
>
> I'd rather not do that, since that would mean every builder
> would have to build src/primes.h, and I'd rather that people used
> the one that's in the tarball, as this avoids a build step
> where things might go wrong (as they did in your case).

Thanks.

That's an argument for having src/primes.h in Git. ;-)

BTW: in which case will that file change? I mean, prime
number are quite static, aren't they?

Have a nice day,
Berny

bug#12903: "cut -b 0-" is supposed to be invalid

[Bernhard Voelker]

Hi Marcel,

On 11/16/2012 07:35 AM, Marcel Böhme wrote:
>Hi,
>The command "echo 12345 | cut -b 0-" prints an empty line while it
>should fail with "fields and positions are numbered from 1" according
>to this specification "cut: diagnose a range starting with 0 (-f 0-2)
>as invalid".
>Can you confirm this is an incomplete bugfix made on 2007-05-22?

I'd say yes.
Here's a proposed fix.

Have a nice day,
Berny


>From 26c6ab75498c4ec6710828799f5452c8243feda1 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Fri, 16 Nov 2012 21:12:16 +0100
Subject: [PATCH] cut: do not accept the range 0-
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/cut.c (set_fields): Add a diagnostic for the invalid open
range which start with Zero, i.e., the range 0-.
* tests/misc/cut.pl: Add a test to ensure the range 0- fails.
* Mention the fix.

Reported by Marcel Böhme.
---
 NEWS  |3 +++
 src/cut.c |3 +++
 tests/misc/cut.pl |3 +++
 3 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index db6a207..9239943 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,9 @@ GNU coreutils NEWS-*- 
outline -*-

 ** Bug fixes

+  cut now does not accept the range 0- any longer.
+  [This bug was present in "the beginning".]
+
   pr -n no longer crashes when passed values >= 32.  Also line numbers are
   consistently padded with spaces, rather than with zeros for certain widths.
   [bug introduced in TEXTUTILS-1_22i]
diff --git a/src/cut.c b/src/cut.c
index 87380ac..2a57148 100644
--- a/src/cut.c
+++ b/src/cut.c
@@ -369,6 +369,9 @@ set_fields (const char *fieldstr)
   dash_found = true;
   fieldstr++;

+  if (lhs_specified && !value)
+FATAL_ERROR (_("fields and positions are numbered from 1"));
+
   initial = (lhs_specified ? value : 1);
   value = 0;
 }
diff --git a/tests/misc/cut.pl b/tests/misc/cut.pl
index 0ce051a..43a5108 100755
--- a/tests/misc/cut.pl
+++ b/tests/misc/cut.pl
@@ -46,6 +46,9 @@ my @Tests =
   # It was treated just like "-2".
   ['zero-2', '-f0-2', {ERR=>$from_1}, {EXIT => 1} ],

+  # Up to coreutils-8.20, specifying a range of 0- was not an error.
+  ['zero-3', '-b0-', {ERR=>$from_1}, {EXIT => 1} ],
+
   ['1', '-d:', '-f1,3-', {IN=>"a:b:c\n"}, {OUT=>"a:c\n"}],
   ['2', '-d:', '-f1,3-', {IN=>"a:b:c\n"}, {OUT=>"a:c\n"}],
   ['3', qw(-d: -f2-), {IN=>"a:b:c\n"}, {OUT=>"b:c\n"}],
-- 
1.7.7

bug#12903: "cut -b 0-" is supposed to be invalid

[Bernhard Voelker]

On 11/16/2012 11:23 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
> 
>> Hi Marcel,
>>
>> On 11/16/2012 07:35 AM, Marcel Böhme wrote:
>>>Hi,
>>>The command "echo 12345 | cut -b 0-" prints an empty line while it
>>>should fail with "fields and positions are numbered from 1" according
>>>to this specification "cut: diagnose a range starting with 0 (-f 0-2)
>>>as invalid".
>>>Can you confirm this is an incomplete bugfix made on 2007-05-22?
>>
>> I'd say yes.
>> Here's a proposed fix.
> ...

> Thank you!
> That change looks fine, at first glance,
> but please amend the log to mention the bug number URL.
> Also, technically this is a bug, so please mention the
> fix in NEWS.

Thanks for the review.

I amended with updated NEWS and also improved the test to include
both the field option -f and the position options -b and -c,
plus mentioned the bug URL in the commit message.

Have a nice day,
Berny


>From 10fc244ac8e4f24eb330eae110fadc0b7d78cf8d Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Sun, 18 Nov 2012 22:20:16 +0100
Subject: [PATCH] cut: do not accept the invalid range 0-
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The command "echo 12345 | cut -b 0-" prints an empty line while
it should fail with "fields and positions are numbered from 1".

* src/cut.c (set_fields): Add a diagnostic for the invalid open
range which starts with Zero, i.e., the range 0-.
* tests/misc/cut.pl: Add tests to ensure the range 0- fails for
fields (-f) and for positions (-b, -c).
* NEWS: Mention the fix.

Reported by Marcel Böhme in <http://bugs.gnu.org/12903>.
---
 NEWS  |4 
 src/cut.c |3 +++
 tests/misc/cut.pl |5 +
 3 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index db6a207..e4a284c 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,10 @@ GNU coreutils NEWS-*- 
outline -*-

 ** Bug fixes

+  cut no longer accepts the invalid range 0-, which made it print empty lines.
+  Instead, cut now fails and emits an appropriate diagnostic.
+  [This bug was present in "the beginning".]
+
   pr -n no longer crashes when passed values >= 32.  Also line numbers are
   consistently padded with spaces, rather than with zeros for certain widths.
   [bug introduced in TEXTUTILS-1_22i]
diff --git a/src/cut.c b/src/cut.c
index 87380ac..2a57148 100644
--- a/src/cut.c
+++ b/src/cut.c
@@ -369,6 +369,9 @@ set_fields (const char *fieldstr)
   dash_found = true;
   fieldstr++;

+  if (lhs_specified && !value)
+FATAL_ERROR (_("fields and positions are numbered from 1"));
+
   initial = (lhs_specified ? value : 1);
   value = 0;
 }
diff --git a/tests/misc/cut.pl b/tests/misc/cut.pl
index 0ce051a..cd56555 100755
--- a/tests/misc/cut.pl
+++ b/tests/misc/cut.pl
@@ -46,6 +46,11 @@ my @Tests =
   # It was treated just like "-2".
   ['zero-2', '-f0-2', {ERR=>$from_1}, {EXIT => 1} ],

+  # Up to coreutils-8.20, specifying a range of 0- was not an error.
+  ['zero-3b', '-b0-', {ERR=>$from_1}, {EXIT => 1} ],
+  ['zero-3c', '-c0-', {ERR=>$from_1}, {EXIT => 1} ],
+  ['zero-3f', '-f0-', {ERR=>$from_1}, {EXIT => 1} ],
+
   ['1', '-d:', '-f1,3-', {IN=>"a:b:c\n"}, {OUT=>"a:c\n"}],
   ['2', '-d:', '-f1,3-', {IN=>"a:b:c\n"}, {OUT=>"a:c\n"}],
   ['3', qw(-d: -f2-), {IN=>"a:b:c\n"}, {OUT=>"b:c\n"}],
-- 
1.7.7

bug#12903: "cut -b 0-" is supposed to be invalid

[Bernhard Voelker]

On 11/19/2012 02:05 AM, Jim Meyering wrote:
> You're welcome to push it.

Thanks, pushed:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1482f730b47d1abad3d75199dde5237d9bf16a4a

Marking as done.

Have a nice day,
Berny

bug#12212: [patch] dd's help text contains superfluous word

[Bernhard Voelker]

On 09/18/2012 04:08 PM, Bernhard Voelker wrote:
> On 09/18/2012 03:20 PM, Jim Meyering wrote:
>> Applied with the above log tweaks.
>> Will push shortly.
> 
> Thanks!

That was commit v8.19-136-g6274128 back on Sep 18th. 2012.
Marked as done.

Have a nice day,
Berny

bug#12940: Deprecated "nl --page-increment" to be removed

[Bernhard Voelker]

tags 12940 + patch
severity 12940 minor
stop

On 11/20/2012 09:42 AM, Marcel Böhme wrote:
>This is no bug per se. Apparently, the deprecated option
>--page-increment for the tool "nl" has been scheduled to be removed on
>Dec. 2011 :)

Hi Marcel,

thanks for the head-up.
Here's a patch.

BTW: Interestingly, there was no test-case for the -i option.
Well, tests/misc/nl.sh doesn't cover too much cases anyway.

Have a nice day,
Berny


>From 31c86a3fe100ac68bf7fc34800bdd615c9e06e88 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Tue, 20 Nov 2012 10:39:19 +0100
Subject: [PATCH] nl: remove deprecated --page-increment option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The above option has been deprecated since coreutils-7.5
by commit v7.4-129-g718b279.

* src/nl.c (PAGE_INCREMENT_OPTION_DEPRECATED): Remove enum.
(longopts): Remove "page-increment" entry.
(main): Remove PAGE_INCREMENT_OPTION_DEPRECATED case.
* NEWS (Remove deprecated options): Mention the change.

Reported by Marcel Böhme in <http://bugs.gnu.org/12940>.
---
 NEWS |5 +
 src/nl.c |   11 ---
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/NEWS b/NEWS
index e4a284c..df4b2e4 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,11 @@ GNU coreutils NEWS-*- 
outline -*-
   field can be in any column.  If there is no source column, then df
   prints 'total' into the target column.

+** Remove deprecated options
+
+  nl no longer supports the --page-increment option which was deprecated
+  since coreutils-7.5.  Use --line-increment instead.
+
 ** Build-related

   Perl is now more of a prerequisite.  It has long been required in order
diff --git a/src/nl.c b/src/nl.c
index 21d4c4d..9a1cdc1 100644
--- a/src/nl.c
+++ b/src/nl.c
@@ -145,11 +145,6 @@ static intmax_t line_no;
 /* True if we have ever read standard input.  */
 static bool have_read_stdin;

-enum
-{
-  PAGE_INCREMENT_OPTION_DEPRECATED = CHAR_MAX + 1
-};
-
 static struct option const longopts[] =
 {
   {"header-numbering", required_argument, NULL, 'h'},
@@ -157,8 +152,6 @@ static struct option const longopts[] =
   {"footer-numbering", required_argument, NULL, 'f'},
   {"starting-line-number", required_argument, NULL, 'v'},
   {"line-increment", required_argument, NULL, 'i'},
-  /* FIXME: page-increment is deprecated, remove in dec-2011.  */
-  {"page-increment", required_argument, NULL, 
PAGE_INCREMENT_OPTION_DEPRECATED},
   {"no-renumber", no_argument, NULL, 'p'},
   {"join-blank-lines", required_argument, NULL, 'l'},
   {"number-separator", required_argument, NULL, 's'},
@@ -513,10 +506,6 @@ main (int argc, char **argv)
   ok = false;
 }
   break;
-  case PAGE_INCREMENT_OPTION_DEPRECATED:
-error (0, 0, _("WARNING: --page-increment is deprecated; "
-   "use --line-increment instead"));
-/* fall through */
 case 'i':
   if (! (xstrtoimax (optarg, NULL, 10, &page_incr, "") == LONGINT_OK
  && 0 < page_incr))
-- 
1.7.7

bug#12940: Deprecated "nl --page-increment" to be removed

[Bernhard Voelker]

On 11/20/2012 11:04 AM, Pádraig Brady wrote:
> On 11/20/2012 09:58 AM, Bernhard Voelker wrote:
>> diff --git a/NEWS b/NEWS
>> index e4a284c..df4b2e4 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -25,6 +25,11 @@ GNU coreutils NEWS-*- 
>> outline -*-
>> field can be in any column.  If there is no source column, then df
>> prints 'total' into the target column.
>>
>> +** Remove deprecated options
> 
> I prefer this item to be under "** Changes in behavior".
> 
> Other than that it looks good to push.

Thanks for the review - pushed with the above change:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=8041e6b62cc829fe6442003fc5be636771a569a1

Marking as done.

Have a nice day,
Berny

bug#12947: [brl...@debian.org: Bug#598018: install: temporary insecure file permissions]

[Bernhard Voelker]

On November 21, 2012 at 3:12 AM Paul Eggert  wrote:
> I pushed this [...]

This is more of a question, and I may be wrong,
but isn't here still a race afterwards?

  execve("src/ginstall", ["src/ginstall", "-g", "video", "-m",
 "664", "src/ginstall", "/tmp/g"], ...) = 0
  ...
  stat("src/ginstall", {st_dev=makedev(8, 16), st_ino=134447,
st_mode=S_IFREG|0755, st_nlink=1,
st_uid=1000, st_gid=100, ...}) = 0
  lstat("/tmp/g", 0x7fff6458b750) = -1 ENOENT (No such file or
directory)
  open("src/ginstall", O_RDONLY)  = 3
  fstat(3, {st_dev=makedev(8, 16), st_ino=134447,
st_mode=S_IFREG|0755, st_nlink=1,
st_uid=1000, st_gid=100, ...}) = 0
  open("/tmp/g", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
  fstat(4, {st_dev=makedev(8, 2), st_ino=18846,
st_mode=S_IFREG|0600, st_nlink=1,
st_uid=1000, st_gid=100, ...}) = 0
  fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
  read(3, ..., 65536) = 65536
  write(4, ..., 65536) = 65536
  ...
  fchmod(4, 0600) = 0
  close(4)= 0
  close(3)= 0

<== ... race? ... ==>

  lchown("/tmp/g", 4294967295, 33)= 0
  chmod("/tmp/g", 0664)   = 0

I.e., after closing FDs 4 and 3, the file "/tmp/g" could
have been replaced. Why aren't we using fchown and
fchmod_or_lchmod before the close() call?

Have a nice day,
Berny

bug#12959: "seq -w -1e-3 9" misaligned

[Bernhard Voelker]

On 11/23/2012 10:04 AM, Pádraig Brady wrote:
> 
> The attached should fix this.

> * src/seq.c (scan_arg): Calculate the width more accurately
> for numbers specified using scientific notation.
> * tests/misc/seq.pl: Add test cases for cases that were mishandled

s/$/./

> * NEWS: Mention the fix.
> * THANKS.in: Reported by Marcel Böhme

s/$/./

And as it's a bug, we should mention it:
  http://bugs.gnu.org/12959

Other than that, the patch looks good.
Thanks.

Have a nice day,
Berny

bug#12959: "seq -w -1e-3 9" misaligned

[Bernhard Voelker]

On 11/23/2012 11:13 AM, Pádraig Brady wrote:
> Thanks for the review!
> Pádraig.

No worries, you're welcome.

For what it's worth, you may also add an integer test case
like "seq -w -1e3 1" which is/was also affected by this bug:

  $ seq -w -1e3 1 | head -n 2
  -1000
  -999

Have a nice day,
Berny

bug#12966: cut: Problems with overlapping, open-ended ranges

[Bernhard Voelker]

On 11/24/2012 08:11 AM, Jim Meyering wrote:

> Subject: [PATCH] cut: interpret "-b3-,2-" like "-b2-", not like "-b3-"

Isn't it the other way round? I.e. "-b3-,2-" has already been working
correctly.

- Subject: [PATCH] cut: interpret "-b3-,2-" like "-b2-", not like "-b3-"
+ Subject: [PATCH] cut: interpret "-b2-,3-" like "-b2-", not like "-b3-"


> diff --git a/NEWS b/NEWS
> index 15fddd4..284525e 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -14,6 +14,10 @@ GNU coreutils NEWS-*- 
> outline -*-
>Instead, cut now fails and emits an appropriate diagnostic.
>[This bug was present in "the beginning".]
> 
> +  cut now handles overlapping right-open-ended ranges properly.  Before,
> +  it would interpret "-b3-,2-" like "-b3-".  Now it's treated like "-b2-".
> +  [This bug was present in "the beginning".]
> +

Likewise.


> diff --git a/THANKS.in b/THANKS.in
> index 016a41e..3080cd3 100644
> --- a/THANKS.in
> +++ b/THANKS.in
> @@ -367,6 +367,7 @@ Marc Haber  
> mh+debian-b...@zugschlus.de
>  Marc Mengel men...@fnal.gov
>  Marc Lehman schm...@schmorp.de
>  Marc Olzheimmarc...@stack.nl
> +Marcel Böhmehaw...@web.de
>  Marco Franzen   marco.fran...@thyron.com
>  Marcus Brinkmannhttp://www.marcus-brinkmann.de
>  Marcus Daniels  mar...@ee.pdx.edu

That change will conflict with Padraig's pending patch for
http://bugs.gnu.org/12959.

Otherwise, the patch looks good.

BTW: interestingly, the i18n patch of openSuSE downstream
already had such a fix included for ages (line 215):
https://build.opensuse.org/package/view_file?file=coreutils-i18n.patch&package=coreutils&project=Base%3ASystem

Have a nice day,
Berny

bug#13030: factor: infinite loop on Linux/powerpc

[Bernhard Voelker]

On 11/29/2012 08:34 PM, Pádraig Brady wrote:
> On 11/29/2012 02:28 PM, Colin Watson wrote:

> The fix looks good thanks.
> I'll commit [...]

Now, "make syntax-check" fails:

  Colin Watson
  maint.mk: remove the above names from THANKS.in
  make: *** [sc_THANKS_in_duplicates] Error 1

Before removing that entry:
Are you the same Colin Watson as in THANKS.in?

  Colin Watsoncj...@riva.ucam.org

Have a nice day,
Berny

bug#13030: factor: infinite loop on Linux/powerpc

[Bernhard Voelker]

On 12/05/2012 11:08 AM, Colin Watson wrote:
> On Wed, Dec 05, 2012 at 09:58:11AM +0100, Bernhard Voelker wrote:
>> Now, "make syntax-check" fails:
>>
>>   Colin Watson
>>   maint.mk: remove the above names from THANKS.in
>>   make: *** [sc_THANKS_in_duplicates] Error 1
>>
>> Before removing that entry:
>> Are you the same Colin Watson as in THANKS.in?
>>
>>   Colin Watsoncj...@riva.ucam.org
> 
> Yes, that's me.  The new address is better.

Thanks, I'll push this soon.

Have a nice day,
Berny

>From 7b4c56b4c65b2b58c185908ff1cbdf0b0399140d Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Wed, 5 Dec 2012 11:47:18 +0100
Subject: [PATCH] maint: remove now auto-added entry from THANKS.in

The syntax-check sc_THANKS_in_duplicates complained about
that excess entry.

* THANKS.in (Colin Watson): Remove entry, now that it will be
automatically included in the generated THANKS file.
---
 THANKS.in |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/THANKS.in b/THANKS.in
index 6a79e04..f0ef9b8 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -128,7 +128,6 @@ Chusslove Illichcaslav.i...@gmx.net
 Clark Morgancmor...@aracnet.com
 Clement Wangclem.w...@overture.com
 Colin Plumb co...@nyx.net
-Colin Watsoncj...@riva.ucam.org
 Collin Rogowski col...@rogowski.de
 Cray-Cyber Project  http://www.cray-cyber.org
 Cristian Cadar  cris...@stanford.edu
-- 
1.7.7

bug#13099: possible test bug in "tests/df/total-verify.sh"

[Bernhard Voelker]

On 12/06/2012 04:39 AM, Assaf Gordon wrote:
> Correction:
> 
> On 12/05/12 22:33, Assaf Gordon wrote:
>> ===
>> $ df --total -i -P
>> Filesystem   Inodes   IUsed IFree IUse% Mounted on
>> < snip >
>> //bluearctitan3/foobar0   0 0 - /media/foobar
>> ===
>>
>> The filesystem is mounted with fuse/sshfs (not sure if that makes a 
>> difference).
> 
> The filesystem is  mounted with CIFS, not sshfs.

Thanks for reporting.

Actually the culprit is not CIFS but the underlying (remote) file system,
i.e. CIFS exposes the inode statistics of e.g. an ext4 file system
properly, while it can not do the same for vfat.

The bug was introduced with my implementation of "df --output" where
the "total" line now also has a "-" in the target ("Mounted on") field.
Well, it seems that none of us had a vfat file system mounted while
running the tests yet.

I wrapped your fix in the following patch.

As there's no official coreutils release yet with that bug, I didn't
add a NEWS entry.

Have a nice day,
Berny

>From d597168b25d58dbd29cf04222608eef262a7d08a Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Thu, 6 Dec 2012 10:11:42 +0100
Subject: [PATCH] tests: fix regex to match "-" in ipcent field in
 df/total-verify.sh

The regular expression failed to match for file systems that
do not provide inode statistics, e.g. VFAT or CIFS (depending
on the underlying peer file system).

* tests/df/total-verify.sh: Fix the regular expression to match
a dash in the ipcent field again.

Reported by Assaf Gordon in http://bugs.gnu.org/13099.
Bug introduced in commit v8.20-18-gdae8d22.
---
 tests/df/total-verify.sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/df/total-verify.sh b/tests/df/total-verify.sh
index 18d215f..5f375bb 100755
--- a/tests/df/total-verify.sh
+++ b/tests/df/total-verify.sh
@@ -32,7 +32,7 @@ while (<>)
 # /dev/sdc1  0   0   0-  /c
 # tmpfs1536000   12965 15230351% /tmp
 # total5285932  787409 4498523   15% -
-/^(.*?) +(-?\d+|-) +(-?\d+|-) +(-?\d+|-) +(?:- |[0-9]+%) (.*)$/
+/^(.*?) +(-?\d+|-) +(-?\d+|-) +(-?\d+|-) +(?:-|[0-9]+%) (.*)$/
   or die "$0: invalid input line\n: $_";
 if ($1 eq 'total' && $5 eq '-')
   {
-- 
1.7.7

bug#13099: possible test bug in "tests/df/total-verify.sh"

[Bernhard Voelker]

On 12/06/2012 10:55 AM, Pádraig Brady wrote:
> That still passes here with a "standard" file system at least.
> Please push.

I could reproduce the failure with a loop-mounted vfat image.

Thanks for the review, pushed:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=43a6ccf0

Have a nice day,
Berny

bug#13119: cp --no-preserve=mode exits 1 since coreutils 8.20

[Bernhard Voelker]

On 12/07/2012 09:43 PM, Florian Pritz wrote:
> Hi,
> 
> I've used the following code in an update script. I don't want cp to
> change permission since the target directory has default ACLs in place
> that will set the correct permissions, but I want to keep timestamps so
> once upon a time I added "--preserve=timestamp
> --nopreserve=mode,ownership". I've tested without mode now and it seems
> permission are fine.
> 
> mkdir a
> touch a/a
> cp -rfT --preserve=timestamps --no-preserve=mode,ownership a b
> 
> If I remove mode from the arguments to --no-preserve it exits 0, but if
> you have it it exits 1 and doesn't print anything. It worked in
> coreutils 8.19 (exit code 0) even though it might not actually do
> anything. If it's intended behaviour you should at least print some kind
> of error message.
> 
> The cause of this change is commit
> 24ebca61a3a0f10d6cd2800b188b3c034d1c4755 but it doesn't say anything
> about changing the exit code.

Thanks for the report.

Outch, yes, unlike in other places, return_val is set to false
unconditionally in copy_reg():

  +  else if (x->explicit_no_preserve_mode)
  +{
  +  set_acl (dst_name, dest_desc, 0666 & ~cached_umask ());
  +  return_val = false;
  +}

And furthermore, the test preserve-mode.sh which would have
detected this error, don't check cp's exit code ;-(

Here's a proposed patch.

Have a nice day,
Berny


>From 62543570d72b756a3b04ca9d1ebec6f4dd2eea4b Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Sat, 8 Dec 2012 19:09:19 +0100
Subject: [PATCH] cp: fix --no-preserve=mode to not exit 1

cp --no-preserve=mode exited 1 unconditionally.  Furthermore,
the tests which would have detected this error - namely
link-preserve.sh and reserve-mode.sh - failed to test
cp's exit code.

* src/copy.c (copy_reg): In the case x->explicit_no_preserve_mode,
do only set return_val to false iff the previous set_acl ()
failed.
* tests/cp/link-preserve.sh: Check cp's exit code.
* tests/cp/link-symlink.sh: Likewise.
* tests/cp/preserve-mode.sh: Likewise.
* NEWS: Mention the fix.

Bug introduced in commit v8.19-145-g24ebca6.

Reported by Florian Pritz in http://bugs.gnu.org/13119.
---
 NEWS  |3 +++
 src/copy.c|4 ++--
 tests/cp/link-preserve.sh |   12 ++--
 tests/cp/link-symlink.sh  |2 +-
 tests/cp/preserve-mode.sh |6 +++---
 5 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/NEWS b/NEWS
index 0e1414c..6576b50 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,9 @@ GNU coreutils NEWS-*- 
outline -*-

 ** Bug fixes

+  cp --no-preserve=mode now no longer exits non-zero.
+  [bug introduced in coreutils-8.20]
+
   cut no longer accepts the invalid range 0-, which made it print empty lines.
   Instead, cut now fails and emits an appropriate diagnostic.
   [This bug was present in "the beginning".]
diff --git a/src/copy.c b/src/copy.c
index 7a35414..0decf9f 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1153,8 +1153,8 @@ preserve_metadata:
 }
   else if (x->explicit_no_preserve_mode)
 {
-  set_acl (dst_name, dest_desc, 0666 & ~cached_umask ());
-  return_val = false;
+  if (set_acl (dst_name, dest_desc, 0666 & ~cached_umask ()) != 0)
+return_val = false;
 }
   else if (omitted_permissions)
 {
diff --git a/tests/cp/link-preserve.sh b/tests/cp/link-preserve.sh
index bb3b244..44768e4 100755
--- a/tests/cp/link-preserve.sh
+++ b/tests/cp/link-preserve.sh
@@ -37,7 +37,7 @@ rm -rf a b c
 touch a
 ln -s a b
 mkdir c
-cp --preserve=links -R -H a b c
+cp --preserve=links -R -H a b c || fail=1
 a_inode=$(ls -i c/a|sed 's,c/.*,,')
 b_inode=$(ls -i c/b|sed 's,c/.*,,')
 test "$a_inode" = "$b_inode" || fail=1
@@ -46,7 +46,7 @@ test "$a_inode" = "$b_inode" || fail=1
 # Ensure that -L makes cp follow the b->a symlink
 # and translates to hard-linked a and b in the destination dir.
 rm -rf a b c d; mkdir d; (cd d; touch a; ln -s a b)
-cp --preserve=links -R -L d c
+cp --preserve=links -R -L d c || fail=1
 a_inode=$(ls -i c/a|sed 's,c/.*,,')
 b_inode=$(ls -i c/b|sed 's,c/.*,,')
 test "$a_inode" = "$b_inode" || fail=1
@@ -54,7 +54,7 @@ test "$a_inode" = "$b_inode" || fail=1

 # Same as above, but starting with a/b hard linked.
 rm -rf a b c d; mkdir d; (cd d; touch a; ln a b)
-cp --preserve=links -R -L d c
+cp --preserve=links -R -L d c || fail=1
 a_inode=$(ls -i c/a|sed 's,c/.*,,')
 b_inode=$(ls -i c/b|sed 's,c/.*,,')
 test "$a_inode" = "$b_inode" || fail=1
@@ -62,7 +62,7 @@ test "$a_inode" = "$b_inode" || fail=1

 # Ensure that --no-preserve=links works.
 rm -rf a b c d; mkdir d; (cd d; touch a; ln a b)

bug#13119: cp --no-preserve=mode exits 1 since coreutils 8.20

[Bernhard Voelker]

On 12/09/2012 01:48 PM, Pádraig Brady wrote:
> The patch looks perfect.

Thanks for the review. Pushed:
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=62543570

Marking the bug as "done".

Have a nice day,
Berny

bug#13172: tail: unrecognized file system type

[Bernhard Voelker]

On 12/13/2012 02:37 PM, coni wrote:
> Hi i've got a warning message in tail command:
> "tail -f /vc/log/apache2/access_log" - report to bug.
>  
> tail (GNU coreutils) 8.20
>  Packaged by Gentoo (8.20 (p1.0))
>  
> - file system type ceph
>  
> message:
>  
> tail: unrecognized file system type 0x00c36400 for 
> '/vc/log/apache2/access_log'.
> please report this to bug-coreutils@gnu.org. reverting to polling
>  
> Regards:
> Conrad.

Thanks for the report.

As a distributed network file system, CEPH seems to be a "remote"
file system, i.e. not supporting inotify.

Conrad, would you mind giving us your full name, so that we can
mention it correctly in THANKS.in?

Here comes the patch.

Have a nice day,
Berny


>From 5997134899c9abd5efd635a446fb1a3975483a82 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Fri, 14 Dec 2012 10:11:51 +0100
Subject: [PATCH] tail,stat: improve support for the ceph file system

Teach tail -f that it must use polling on ceph file systems, and
let stat -f --format=%T report the file system type name, "ceph".
Website: http://ceph.com/

* src/stat.c (human_fstype): Add a case: ceph, 0x00c36400, remote.
* NEWS (Improvements): Mention it.
* THANKS.in: Update.
Reported by Conrad  in http://bugs.gnu.org/13172.
---
 NEWS   |6 ++
 THANKS.in  |1 +
 src/stat.c |2 ++
 3 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index e22d3a9..1ee2c17 100644
--- a/NEWS
+++ b/NEWS
@@ -59,6 +59,12 @@ GNU coreutils NEWS-*- 
outline -*-
   nl no longer supports the --page-increment option which was deprecated
   since coreutils-7.5.  Use --line-increment instead.

+** Improvements
+
+  stat and tail now know about CEPH.  stat -f --format=%T now reports the file
+  system type, and tail -f uses polling for files on CEPH file systems.
+
+
 ** Build-related

   Perl is now more of a prerequisite.  It has long been required in order
diff --git a/THANKS.in b/THANKS.in
index f0ef9b8..802e52d 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -129,6 +129,7 @@ Clark Morgancmor...@aracnet.com
 Clement Wangclem.w...@overture.com
 Colin Plumb co...@nyx.net
 Collin Rogowski col...@rogowski.de
+Conrad ??   c...@o2.pl
 Cray-Cyber Project  http://www.cray-cyber.org
 Cristian Cadar  cris...@stanford.edu
 Cyril Bouthors  cy...@bouthors.org
diff --git a/src/stat.c b/src/stat.c
index 51f4b90..6283566 100644
--- a/src/stat.c
+++ b/src/stat.c
@@ -266,6 +266,8 @@ human_fstype (STRUCT_STATVFS const *statfsbuf)
   return "binfmt_misc";
 case S_MAGIC_BTRFS: /* 0x9123683E local */
   return "btrfs";
+case S_MAGIC_CEPH: /* 0x00c36400 remote */
+  return "ceph";
 case S_MAGIC_CGROUP: /* 0x0027E0EB local */
   return "cgroupfs";
 case S_MAGIC_CIFS: /* 0xFF534D42 remote */
-- 
1.7.7

bug#13172: tail: unrecognized file system type

[Bernhard Voelker]

On 12/14/2012 10:28 AM, Pádraig Brady wrote:
> On 12/14/2012 09:18 AM, Bernhard Voelker wrote:
>> +case S_MAGIC_CEPH: /* 0x00c36400 remote */
>> +  return "ceph";
> 
> s/00c/00C/ for consistency
> 
> thanks for handling this.
> Pádraig.

Thanks for the review.
Konrad also confirmed that it works offline.

Pushed:
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=c321f745

Marking as done.

Have a nice day,
Berny

bug#13227: seq -s broken in coretutils 8.20?

[Bernhard Voelker]

On 12/20/2012 01:33 AM, Pádraig Brady wrote:
> The attached should fix it.

The patch looks good, thanks.

Have a nice day,
Berny

bug#13243: closed (Re: bug#13243: [PATCH] enhancement: modify md5sum to allow piping)

[Bernhard Voelker]

On 12/21/2012 12:12 AM, Daniel Santos wrote:
> On 12/20/2012 11:49 PM, Eric Blake wrote:
>> dd if=/dev/sda3 | pbzip2 -c2 | tee >(md5sum > /tmp/sda3.dat.bzip2.md5) |
>> netcat 192.168.1.123 45678

> Wow! It was worth writing a patch just to discover the >(list) and 
> <(list) constructs.  I knew about tee, but I had no idea about this, 
> thanks!! I've even known how to do this across programs written in C, I 
> just didn't know there was a bash mechanism for it.  So I guess bash 
> substitutes the parameter name with the /dev/fd or some such for the 
> named pipe it creates?  I'll have to read up on it more.

Without bash, you can do it manually with a named pipe:

  mkfifo /tmp/fifo

  md5sum /tmp/fifo > /tmp/sda3.dat.bzip2.md5 &

  dd if=/dev/sda3 | pbzip2 -c2 | tee > /tmp/fifo |
  netcat 192.168.1.123 45678

Have fun,
Berny

bug#13280: od 8.19: inappropriate formatting of the man pages

[Bernhard Voelker]

On December 27, 2012 at 12:42 PM "Pádraig Brady"  wrote:
> On 12/26/2012 07:43 AM, Akim Demaille wrote:
> I've adjusted things a bit in the attached patch,

Looks good. As it was reported as a bug, shouldn't
we mention it in the commit message:

  - Reported by Akim Demaille.
  + Reported by Akim Demaille in http://bugs.gnu.org/13280.

and (maybe even) in NEWS?

For NEWS, the change may be too marginal, but at least
a reference in Git would be great IMO.

Have a nice day,
Berny

bug#13389: echo command redhat linux OS

[Bernhard Voelker]

tag 13389 notabug
thanks

On 01/08/2013 06:57 AM, Mohanad Azzam wrote:
> Dears
> 
> Could we print values to be as three column ,each column present the values 
> of each file.
> 
> More explanation :
> I have three files ,each file include a queue of values .I need to print all 
> the values by one command to be in one page
> 
> Thanks

Without a sample of your data, this sounds like you
want to use join.

Given you have the 3 files X, Y and Z with the following content:

  $ cat X
  1 x1
  2 x2
  3 x3

  $ cat Y
  1 y1
  2 y2
  3 y3

  $ cat Z
  1 z1
  2 z2
  3 z3

If you don't have the line numbers, then you can easily
create them with e.g. "cat -n X".

Then you can join X and Y (column 1 will be the key),
and join the result (indicated by stdin "-") with Z:

  $ join X Y | join - Z
  1 x1 y1 z1
  2 x2 y2 z2
  3 x3 y3 z3

Have a nice day,
Berny

bug#13391: dd silently ignores lseek error

[Bernhard Voelker]

On 01/09/2013 02:14 AM, Pádraig Brady wrote:
> I had a look around for a tool to verify
> that a file/device supports the seek operation
> and couldn't find one.
> So this seems like useful functionality.
> Worth applying the attached?

> * cfg.mk (sc_dd_O_FLAGS): Add O_SEEKABLE to the list of private
> flags with a a single underscore.

s/a a/a/

> @@ -619,6 +628,9 @@ Each FLAG symbol may be:\n\
>if (O_SEEK_BYTES)
>  fputs (_("  seek_bytes  treat 'seek=N' as a byte count (oflag 
> only)\n\
>  "), stdout);
> +  if (O_SEEKABLE)
> +fputs (_("  seekable  fail unless seekable\n\
> +"), stdout);

no line break needed here.

> +  offset = lseek (STDOUT_FILENO, 0, SEEK_CUR);
> +  output_seekable = (0 <= offset);
> +  if (! input_seekable && (input_flags & O_SEEKABLE))
> +{
> +  error (EXIT_FAILURE, input_seek_errno, _("input is not seekable %s"),
> + quote (input_file));
> +}

why not check input_seekable where it is set - ~60 lines above?

Have a nice day,
Berny

bug#13394: Misalignment for "seq -w"

[Bernhard Voelker]

On 01/09/2013 11:14 AM, Marcel Böhme wrote:
> Dear all,
> 
> There are the following problems with the -w parameter of the seq tool:
> 
> $seq -w -1 1.0 0
> -1.0
> 0.0
> 1.0
> 
> But it should print:
> -1.0
> 00.0
> 01.0

Hmm, according to the TEXI manual, the FIRST number should also use
a fixed point decimal representation when the -w option is used:

`-w'
`--equal-width'
 Print all numbers with the same width, by padding with leading
 zeros.  FIRST, STEP, and LAST should all use a fixed point decimal
 representation.  (To have other kinds of padding, use `--format').

Thus, seq is just doing what the manual says:

  $ seq -w -1.0 1.0 0.0
  -1.0
  00.0

But that leaves the question open if there's a reason for this.
I.e. if it's just documented behavior, a requirement of some
standard or due to compatibility reasons.

But as Padraig worked in this area recently ([1]), I think there
is further room for improvement ... and then the documentation
should be fixed.

@Padraig: WDYT?

Have a nice day,
Berny

[1] http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=64d4a280

bug#13394: Misalignment for "seq -w"

[Bernhard Voelker]

On 01/09/2013 01:05 PM, Pádraig Brady wrote:
> Looks like a bug. I'll fix with:
> 
> diff --git a/src/seq.c b/src/seq.c
> index e1b467c..3eb53f8 100644
> --- a/src/seq.c
> +++ b/src/seq.c
> @@ -332,6 +332,8 @@ get_default_format (operand first, operand step, operand 
> last)
>   last_width--;  /* don't include space for '.' */
> if (last.precision == 0 && prec)
>   last_width++;  /* include space for '.' */
> +  if (first.precision == 0 && prec)
> +first_width++;  /* include space for '.' */
> size_t width = MAX (first_width, last_width);
> if (width <= INT_MAX)
>   {

+1

Have a nice day,
Berny

bug#13447: ln "" foo gives misleading error message

[Bernhard Voelker]

On 01/15/2013 09:23 AM, Ken Irving wrote:
> (Previously sent in error to the bug-gnu-utils list.)
> 
> I've been using symbolic links in a non-file-related way, e.g., to store
> arbitrary string values, but find that if I try to create a symlink with
> an empty 'target' name, e.g., as 'ln -s "" foo', the error message emitted
> is not really correct.
> 
> $ ln -s "" foo
> ln: creating symbolic link `foo' -> `': No such file or directory
> $ ln -sf "" foo
> ln: creating symbolic link `foo' -> `': No such file or directory
> 
> A link can be created when no file or directory exists, e.g.,
> 
> $  stat x || ln -s x foo && echo ok
> stat: cannot stat `x': No such file or directory
> ok
> 
> so it seems that 'No such file or directory' must not be the actual
> reason for the failure.  Perhaps something like 'null target name'
> would be more accurate?
> 
> I only happened upon this in working on a test script, and have no
> expectation for the operation to succeed.
> 
> Thanks
> 
> Ken Irving

Thanks for the report, however this particular issue has previously
dicussed:
http://lists.gnu.org/archive/html/coreutils/2012-11/msg8.html

The problem is that some coreutils programs do handle this special
case - i.e. "" as argument for file names - while others do not.
But no-one came up with patches to fix it yet - including me ;-)

Have a nice day,
Berny

bug#13447: ln "" foo gives misleading error message

[Bernhard Voelker]

On 01/15/2013 10:44 AM, Bob Proulx wrote:
> Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> Interestingly I notice that solaris for example allows a NULL old_path.
>>
>> That Solaris behavior is contrary to POSIX 2008
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
> 
> Where does it say this?  I read it through in detail but I didn't see
> that it required a diagnostic to be emitted in the case that value is
> am empty string.  What did I miss?

Right, the only 3 statements about path1 are:

 * The string pointed to by path1 shall be treated only as a
   character string and shall not be validated as a pathname.

 * [ENAMETOOLONG]
   [...] or the length of the path1 argument is longer than {SYMLINK_MAX}.

 * [...] in fact, the file named by the path1 argument need not exist
   when the link is created.

I'd read this as:
a) there can be any character in the string but a NULL (obviously).
b) the maximum length is limited to SYMLINK_MAX.
Nothing more.

BUT:
Some CU tools already catch zero-length file names (du and wc),
and a comment in the code states that FTS has problems with it
[src/du.c:1043]:

 /* Report and skip any empty file names before invoking fts.
 This works around a glitch in fts, which fails immediately
 (without looking at the other file names) when given an empty
 file name.  */


Have a nice day,
Berny

bug#13453: comm

[Bernhard Voelker]

On 01/16/2013 05:53 PM, Dennis Miller wrote:
> My version doesn't have those options.  I'm running
> GNU coreutils 5.97-34.el5_8.1.  What version has these options?

The option --check-order has been added in coreutils-7.0 back in 2008.

Have a nice day,
Berny

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

[Bernhard Voelker]

On 01/22/2013 01:17 PM, Pádraig Brady wrote:
> Updated patch attached.

That one is looking good ... but while we're at it:

Anyone tried this, i.e. a Zero as INCREMENT?

  $ seq 1 0 2

This is equal to `yes 0`. Well, this is probably a (not
documented) feature, but in the following examples, the "1"
should be printed only once, shouldn't it?

  $ seq 1 0 1
  $ seq 1 0.0 1

(BTW: "seq 2 0 1" works, i.e. doesn't print anything.)

Have a nice day,
Berny

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

[Bernhard Voelker]

On 01/22/2013 02:24 PM, Pádraig Brady wrote:
> Yes I was wondering that myself.
> 
> Though I suppose that `seq 0 0 1` prints endlessly,
> means that it's consistent that as long as start <= end
> and step == 0, then start is printed endlessly.

Yes, from a mathematical point of view, seq is right.
Therefore, maybe documenting seq's behavior would suffice.
OTOH ...

> Maybe we should special case to only print
> the start value once if step = 0.

... users may not be amused about an endless loop in a tool
which is otherwise meant for counting, e.g.

  $ seq $start $step $last | \
  while read x ; do work_on $s ; done

Stopping after the start valie is maybe not mathematically
correct, but more "natural".

> Maybe one could use a step of 0 to hack a
> min/max function or something?
>
>min() { minv=$(seq "$1" 0 "$2"); : ${minv:="$2"}; echo $minv; }
>max() { minv=$(seq "$1" 0 "$2"); : ${maxv:="$1"}; echo $maxv; }

TBH this doesn't look like as if a normal user would be
able to invent this. ;-)

Have a nice day,
Berny

bug#13530: head: memory exhausted when printing all from stdin but last P/E bytes

[Bernhard Voelker]

On 01/23/2013 01:34 PM, Pádraig Brady wrote:
> There is the argument that we _should_ allocate
> everything up front to indicate immediately
> that the system can't (currently) support the requested operation,
> but given the 'currently' caveat above I guess it's
> more general to fail when we actually run out of mem?

head doesn't "allocate everything up front" - instead, it only
allocates the pointer array which would hold the actual data.
The strategy in elide_tail_lines_pipe() seems more robust:
it allocates memory when needed.

Or another (probably martian) idea:
what about a tmpfile()?

>   free_mem:
> -  for (i = 0; i < n_bufs; i++)
> +  for (i = 0; i < n_alloc; i++)
>   free (b[i]);
> free (b);

BTW: both in the old and the new version, the loop can break
if (b[i] == 0) because the array is filled from the beginning.

-  for (i = 0; i < n_bufs; i++)
+  for (i = 0; i < n_bufs && b[i]; i++)

This makes "echo 123 | head -c -T" ~40% faster here on my PC.

Have a nice day,
Berny

bug#13530: head: memory exhausted when printing all from stdin but last P/E bytes

[Bernhard Voelker]

On 01/23/2013 02:03 PM, Pádraig Brady wrote:
> On 01/23/2013 12:53 PM, Bernhard Voelker wrote:
>> head doesn't "allocate everything up front" - instead, it only
>> allocates the pointer array which would hold the actual data.
> 
> Sure. I was wondering whether that should change
> to allocate everything up front so as to exit early.

I think that's not a good idea because head would ENOMEM
even if it doesn't wouldn't need the memory (depending on the
input). Why should the following fail?

  $ echo 123 | head -c -T

I think there's no reason to fail until we really know it would
fail. In this case, we can only know it when we actually come
to the point when we need the memory.

It doesn't matter if we have
  $ echo 123 | head -c -10
or
  $ echo 123 | head -c -P

>>>free_mem:
>>> -  for (i = 0; i < n_bufs; i++)
>>> +  for (i = 0; i < n_alloc; i++)
>>>free (b[i]);
>>>  free (b);
>>
>> BTW: both in the old and the new version, the loop can break
>> if (b[i] == 0) because the array is filled from the beginning.
> 
> The new version only frees what's allocated and so gets this benefit too.

ah yes, sorry, I didn't look close enough.

Have a nice day,
Berny

bug#13538: sort wrong

[Bernhard Voelker]

tag 13538 + notabug
close 13538
stop

On 01/24/2013 07:16 AM, XU Jian H wrote:
> $ cat log
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/res
> /VOBS/MediaGW/gw/src/res
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src@@/m
> /VOBS/MediaGW/gw/src@@/m
> /VOBS/MediaGW/gw/src@@/m
> 
> $ ~/bin/sort --version
> sort (GNU coreutils) 8.20
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Mike Haertel and Paul Eggert.
> 
> $ ~/bin/sort log
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src@@/m
> /VOBS/MediaGW/gw/src@@/m
> /VOBS/MediaGW/gw/src@@/m
> /VOBS/MediaGW/gw/src/res
> /VOBS/MediaGW/gw/src/res
> 
> But I expect the result should be:
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/cha
> /VOBS/MediaGW/gw/src/res
> /VOBS/MediaGW/gw/src/res
> /VOBS/MediaGW/gw/src@@/m
> /VOBS/MediaGW/gw/src@@/m
> /VOBS/MediaGW/gw/src@@/m

Hi xujian,

I didn't know Alcatel is also (still) using ClearCase ;-)

Re. the problem:

The sort order is dependent on your locale setting.
E.g. with LC_ALL=C, the result will be as you expected
while with LC_ALL=en_US.UTF-8, the result is the one you
got.

  $ LANG=C src/sort /tmp/x
  /VOBS/MediaGW/gw/src/cha
  /VOBS/MediaGW/gw/src/cha
  /VOBS/MediaGW/gw/src/cha
  /VOBS/MediaGW/gw/src/cha
  /VOBS/MediaGW/gw/src/res
  /VOBS/MediaGW/gw/src/res
  /VOBS/MediaGW/gw/src@@/m
  /VOBS/MediaGW/gw/src@@/m
  /VOBS/MediaGW/gw/src@@/m

More on this:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021

Therefore, I'm marking this bug as done.

Have a nice day,
Berny

bug#13535: timeout command not working when SIGALRM blocked

[Bernhard Voelker]

On 01/25/2013 04:12 AM, Pádraig Brady wrote:
> I agree with your patch, and have attached an updated version.

+1 if you mention http://bugs.gnu.org/13535.

Have a nice day,
Berny