bug#66294: Formal Bug Report in paste.c of Coreutils Version 9.0 by Klee

[Paul Eggert]

I looked at the text version of the bug report and don't understand it. 
Can you please rephrase the bug report so that you tell us how you 
invoked 'paste' (command line arguments and input file contents), what 
behavior you expected, and what behavior you observed? Please bear in 
mind that your readers might not know about klee. Thanks.

bug#66294: Fwd: bug#66294: Formal Bug Report in paste.c of Coreutils Version 9.0 by Klee

[Paul Eggert]

Forwarding this attachment to <66...@debbugs.gnu.org> as it got lost in 
my spam inbox when it got sent just to me.


 Forwarded Message 
Subject: Re: bug#66294: Formal Bug Report in paste.c of Coreutils 
Version 9.0 by Klee

Date: Mon, 02 Oct 2023 10:53:57 +
From: JediWisdomKeeper 
To: Paul Eggert 






Sent with Proton Mail secure email.

--- Original Message ---
On Monday, October 2nd, 2023 at 6:45 AM, Paul Eggert 
 wrote:




Would you please resend your bug report as plain text? Thanks.Command used: klee --simplify-sym-indices --write-cvcs --write-cov 
--output-module --max-memory=1000 --disable-inlining --optimize 
--use-forked-solver --use-cex-cache --libc=uclibc --posix-runtime 
--external-calls=all --only-output-states-covering-new 
--max-sym-array-size=4096 --max-solver-time=30s --max-time=1min --watchdog 
--max-memory-inhibit=false --max-static-fork-pct=1 --max-static-solve-pct=1 
--max-static-cpfork-pct=1 --switch-type=internal --search=random-path 
--search=nurs:covnew --use-batching-search --batch-instructions=1 
./paste.bc --sym-args 0 1 10 --sym-args 0 2 2 --sym-files 1 8 --sym-stdin 8 
--sym-stdout






  

Error1 output as reported by KLEE


ktest file : 'test01.ktest'
args   : ['./paste.bc', '--sym-args', '0', '1', '10', '--sym-args', 
'0', '2', '2', '--sym-files', '1', '8', '--sym-stdin', '8', '--sym-stdout']
num objects: 11
object  0: name: 'n_args'
object  0: size: 4
object  0: data: b'\x01\x00\x00\x00'
object  0: hex : 0x0100
object  0: int : 1
object  0: uint: 1
object  0: text: 
object  1: name: 'arg00'
object  1: size: 11
object  1: data: b'-\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff'
object  1: hex : 0x2d00ff
object  1: text: -..
object  2: name: 'n_args'
object  2: size: 4
object  2: data: b'\x02\x00\x00\x00'
object  2: hex : 0x0200
object  2: int : 2
object  2: uint: 2
object  2: text: 
object  3: name: 'arg01'
object  3: size: 3
object  3: data: b'\x00\x00\x00'
object  3: hex : 0x00
object  3: text: ...
object  4: name: 'arg02'
object  4: size: 3
object  4: data: b'\x00\x00\x00'
object  4: hex : 0x00
object  4: text: ...
object  5: name: 'A_data'
object  5: size: 8
object  5: data: b'\x00\x00\x00\x00\x00\x00\x00\x00'
object  5: hex : 0x
object  5: int : 0
object  5: uint: 0
object  5: text: 
object  6: name: 'A_data_stat'
object  6: size: 144
object  6: data: 
b'6\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x00\x00\x00\x00\xa4\x81\x00\x00\xe8\x03\x00\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\x00\x10\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xc1\x93\x10e\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff{\xf0\x11e\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff{\xf0\x11e\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
object  6: hex : 
0x360001000100a481e803e8030010c19310657bf011657bf01165
object  6: text: 
6..e{..e{..e
object  7: name: 'stdin'
object  7: size: 8
object  7: data: b'\x00\x00\x00\x00\x00\x00\x00\x00'
object  7: hex : 0x
object  7: int : 0
object  7: uint: 0
object  7: text: 
object  8: name: 'stdin_stat'
object  8: size: 144
object  8: data: 
b'6\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x00\x00\x00\x00\xa4\x81\x00\x00\xe8\x03\x00\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\x00\x10\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xc1\x93\x10e\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff{\xf0\x11e\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff{\xf0\x11e\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
object  8: hex : 
0x360001000100a481e803e8030010c19310657bf011657bf01165
object  8: text: 
6..

bug#66294: Formal Bug Report in paste.c of Coreutils Version 9.0 by Klee

[Paul Eggert]

Would you please resend your bug report as plain text? Thanks.

bug#59819: Acknowledgement (Bug Report: [coreutils] echo command interprets wildcards, when read with the 'cat' command from a file, in a for-in loop)

[th3_d0ctor]

I missed the quote.
Sorry for my bad.

Kind regards



Am Sun, 04 Dec 2022 16:54:02 +
schrieb help-debb...@gnu.org (GNU bug Tracking System):

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-coreutils@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 59...@debbugs.gnu.org.
>
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>

bug#59819: Bug Report: [coreutils] echo command interprets wildcards, when read with the 'cat' command from a file, in a for-in loop

[Andreas Schwab]

On Dez 04 2022, th3_d0ctor wrote:

> $ echo "*" >b; for i in `cat b`; do echo "$i"; done
> ==> list current working directory instead of printing the wildcard '*'

That's how it is supposed to work, since file name expansion is
performed after all other expansions (just before quote removal).

This is basic shell operation knowledge that everyone using the shell
should remember.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57132: bug report

[Pádraig Brady]

tag 57132 notabug
close 57132
stop

On 11/08/2022 04:05, lingzhiyuan (袁凌志) wrote:

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

[cid:image001.jpg@01D8AD72.4C974A50]


This was addressed in coreutils release 8.25 (2016-01-20).
Please update to something newer than that.

thank you.

bug#57132: bug report

[袁凌志]

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

[cid:image001.jpg@01D8AD72.4C974A50]

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

[Paul Eggert]

On 2/14/22 01:41, Stéphane Archer wrote:

is +'%Y-%m-%dT%H:%M:%S.0Z' do what I want


To format an arbitrary timestamp you want "+%Y-%m-%dT%H:%M:%S.%1NZ", 
unless you always want a zero after the period.


Closing the bug report as there's no bug here.

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

[Stéphane Archer]

Hi Andreas,

thank you for your help, I didn't realize I was using the wrong format for
what I wanted.
I don't have much experience with the project.
The format I wanted was: -MM-DDThh:mm:ss.sZ
is +'%Y-%m-%dT%H:%M:%S.0Z' do what I want or are there still some mistakes
there?

Thank you again and sorry for the bug report, it was late and I was sure to
have found a bug ^^"

Best regards

Stéphane Archer


On Mon, Feb 14, 2022 at 9:17 AM Andreas Schwab 
wrote:

> On Feb 13 2022, Stéphane Archer wrote:
>
> > $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> > 2022-12-25T17:00:00.0Z
> > $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> > 2022-01-01T17:00:00.0Z
> > $ date -d "17 april 2022 + 38 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> > 2023-01-08T17:00:00.0Z
> > ```
> > as you can see the input "17 april 2022 + 37 week 5pm" makes date return
> > the wrong output for some unknown reason.
>
> It doesn't make sense to use %G without %V, or to use it in place of %Y.
>
> $ date -d "17 april 2022 + 37 week 5pm" +'%G/%V %Y-%m-%dT%H:%M:%S.0Z'
> 2022/52 2023-01-01T17:00:00.0Z
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>


-- 
Best Regards,

Stephane Archer

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

[Andreas Schwab]

On Feb 13 2022, Stéphane Archer wrote:

> $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> 2022-12-25T17:00:00.0Z
> $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> 2022-01-01T17:00:00.0Z
> $ date -d "17 april 2022 + 38 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> 2023-01-08T17:00:00.0Z
> ```
> as you can see the input "17 april 2022 + 37 week 5pm" makes date return
> the wrong output for some unknown reason.

It doesn't make sense to use %G without %V, or to use it in place of %Y.

$ date -d "17 april 2022 + 37 week 5pm" +'%G/%V %Y-%m-%dT%H:%M:%S.0Z'
2022/52 2023-01-01T17:00:00.0Z

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

[Stéphane Archer]

Hi,
I hope this is the right place to do my bug report.
please see the following shell input-output:
```
$ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
2022-12-25T17:00:00.0Z
$ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
2022-01-01T17:00:00.0Z
$ date -d "17 april 2022 + 38 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
2023-01-08T17:00:00.0Z
```
as you can see the input "17 april 2022 + 37 week 5pm" makes date return
the wrong output for some unknown reason.

Do I do something wrong?
I use the following version: date (GNU coreutils) 8.30

-- 
Best Regards,

Stephane Archer

bug#46720: bug report

[pawns4unme]

attached is a bug report... I am compiling LFS 10 on an HP Pavilion G6 
Laptop..This happened in chapter 8 after issuing this command...
 
   GNU coreutils 8.32: ./tests/test-suite.log


# TOTAL: 32
# PASS:  14
# SKIP:  13
# XFAIL: 0
# FAIL:  5
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: tests/cp/cp-a-selinux
===

++ initial_cwd_=/sources/coreutils-8.32
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /sources/coreutils-8.32 gt-cp-a-selinux.sh.
+++ case $# in
+++ destdir_=/sources/coreutils-8.32
+++ template_=gt-cp-a-selinux.sh.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ destdir_slash_=/sources/coreutils-8.32/
+++ case $template_ in
 unset TMPDIR
+++ d=/sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
+++ case $d in
+++ :
+++ test -d /sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
 ls -dgo /sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
+++ perms='drwx-- 2 4096 Feb 23 09:38 /sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o'
+++ case $perms in
+++ :
+++ echo /sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
+++ return
++ test_dir_=/sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
++ cd /sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
++ case $srcdir in
++ srcdir=../.
++ builddir=..
++ export srcdir builddir
++ 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
+ abs_path_dir_=/sources/coreutils-8.32/./src
+ case $abs_path_dir_ in
+ PATH=/sources/coreutils-8.32/./src:/sources/coreutils-8.32/src:/bin:/usr/bin:/sbin:/usr/sbin
+ create_exe_shims_ /sources/coreutils-8.32/./src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ cp
+ require_built_ cp
+ skip_=no
+ for i in "$@"
+ case " $built_programs " in
+ test no = yes
+ test yes = yes
+ local i
+ for i in $*
+ env cp --version
cp (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
+ require_root_
+ uid_is_privileged_
++ id -u
+ my_uid=0
+ case $my_uid in
+ NON_ROOT_USERNAME=tester
++ id -g tester
+ NON_ROOT_GID=0
+ grep '^[ ]*chroot' .././tests/cp/cp-a-selinux.sh
+ require_selinux_
+ grep 'selinuxfs$' /proc/filesystems
+ skip_ 'this system lacks SELinux support'
+ warn_ 'cp-a-selinux.sh: skipped test: this system lacks SELinux support'
+ case $IFS in
+ printf '%s\n' 'cp-a-selinux.sh: skipped test: this system lacks SELinux support'
cp-a-selinux.sh: skipped test: this system lacks SELinux support
+ test 9 = 2
+ sed 1q
+ printf '%s\n' 'cp-a-selinux.sh: skipped test: this system lacks SELinux support'
+ Exit 77
+ set +e
+ exit 77
+ exit 77
+ remove_tmp_
+ __st=77
+ cleanup_
+ :
+ test '' = yes
+ cd /sources/coreutils-8.32
+ chmod -R u+rwx /sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
+ rm -rf /sources/coreutils-8.32/gt-cp-a-selinux.sh.dk2o
+ exit 77
SKIP tests/cp/cp-a-selinux.sh (exit status: 77)

FAIL: tests/cp/special-bits
===

++ initial_cwd_=/sources/coreutils-8.32
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /sources/coreutils-8.32 gt-special-bits.sh.
+++ case $# in
+++ destdir_=/sources/coreutils-8.32
+++ template_=gt-special-bits.sh.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ destdir_slash_=/sources/coreutils-8.32/
+++ case $template_ in
 unset TMPDIR
+++ d=/sources/coreutils-8.32/gt-special-bits.sh.CP1e
+++ case $d in
+++ :
+++ test -d /sources/coreutils-8.32/gt-special-bits.sh.CP1e
 ls -dgo /sources/coreutils-8.32/gt-special-bits.sh.CP1e
+++ perms='drwx-- 2 4096 Feb 23 09:38 /sources/coreutils-8.32/gt-special-bits.sh.CP1e'
+++ case $perms in
+++ :
+++ echo /sources/coreutils-8.32/gt-special-bits.sh.CP1e
+++ return
++ test_dir_=/sources/cor

bug#45832: CYBER HACK URGENT BUG REPORT

[Bernhard Voelker]

tag 45832 notabug
close 45832
stop

On 1/12/21 10:33 PM, hayley novelli wrote:
> https://www.gnu.org/software/coreutils/coreutils
> 
> 
> 
> https://dl.bintray.com/grimler/science-packages-24 science/stable aarch64 
> Packages [8936<https://www.gnu.org/software/coreutils/coreutils>
> 
> 
> bintray located in s20 5g
> remote access
> 
> aarch64
> heimdallddata files
> daemons located
> sandbox
> z-ram
> USB update
> 
> your companion
> 
> activities in Google download
> screen share Microsoft
> free text & call apps
> 
> etc...
> 
> much more attachments to be forwarded now transferred to s9
> 
> after factory reset restore
> 
> 0433942419
> Hayley Michele
> 30 Louise avenue baulkham hills
> 2153

Sorry - is that a bug report?

You reached the GNU coreutils mailing list, but neither in the text provided
above nor in the (bloaty 3M!) screenshots I can see anything like a bug
description or a reproducer.

The only thing which is somehow clear is that you did something with
a (Samsung?) mobile phone, and that you live in Australia.
But I don't see the slightest relation to the coreutils, sorry.
Well, only the URL to the gnu.org page at the top.

Thus, I'm closing this as as not-a-bug in our bug tracker.

Have a nice day,
Berny

bug#41920: sort: bug report/feature request: warn is -t is effectively a no-op?

[Eric Blake]

On 6/17/20 7:22 AM, Jacek Wielemborek wrote:

Hi!

First of all, thanks for maintaining GNU sort! I use it very often and love
its performance.

Today I spent some time debugging and realized that my bug was caused by a
wrong GNU invocation ("sort -k1,1 -t," instead of "sort -t, -k1,1"). Could
sort warn when -t is effectively a no-op because it was specified after
last -k?


Except that statement does not appear to be true.  sort does not care 
whether -t comes before or after -k; there is no interlocking between 
the two options (looking at the source code, nothing under case 't' [1] 
depends on the current set of keys, and nothing under case 'k' [2] 
depends on the current 'tab').


[1] https://git.sv.gnu.org/cgit/coreutils.git/tree/src/sort.c#n4520
[2] https://git.sv.gnu.org/cgit/coreutils.git/tree/src/sort.c#n4441

To convince me otherwise, could you include actual input where the 
relative ordering of the two options produces different output?



I know that `find` warns the user if arguments are in a wrong
order, perhaps it would make sense to add it here as well?


We have 'sort --debug' for this sort of things.  If the ordering truly 
mattered, then yes, --debug should warn about that.  But I can't see the 
ordering matter.  Here's what I tried, where the first two tries show 
that the position of -t, doesn't affect the output, and the third shows 
that omitting -t, does matter:


$ printf '1,2 3\n2,1 4\n' | LC_ALL=C sort -k2,2 -t, --debug
sort: text ordering performed using simple byte comparison
2,1 4
  ___
_
1,2 3
  ___
_
$ printf '1,2 3\n2,1 4\n' | LC_ALL=C sort -t, -k2,2 --debug
sort: text ordering performed using simple byte comparison
2,1 4
  ___
_
1,2 3
  ___
_

$ printf '1,2 3\n2,1 4\n' | LC_ALL=C sort -k2,2 --debug
sort: text ordering performed using simple byte comparison
sort: leading blanks are significant in key 1; consider also specifying 'b'
1,2 3
   __
_
2,1 4
   __
_


I'll leave this bug open a bit longer to allow you to reply with the 
counterexample that behaved differently based solely on ordering, but 
I'm inclined to close it if we can't come up with such a case.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

bug#41920: sort: bug report/feature request: warn is -t is effectively a no-op?

[Jacek Wielemborek]

Hi!

First of all, thanks for maintaining GNU sort! I use it very often and love
its performance.

Today I spent some time debugging and realized that my bug was caused by a
wrong GNU invocation ("sort -k1,1 -t," instead of "sort -t, -k1,1"). Could
sort warn when -t is effectively a no-op because it was specified after
last -k? I know that `find` warns the user if arguments are in a wrong
order, perhaps it would make sense to add it here as well?

(I read FAQ/list of gotchas, but believe that my case is a bit different
compared to the ones listed there)

Cheers,
d33tah

bug#40183: bug-report

[Kew ��]

unrecognized file system type 0x794c7630 for ??error.log??. please report this 
to bug-coreutils@gnu.org. reverting to polling

bug#39879: Bug report

[Pádraig Brady]

On 03/03/2020 06:15, Scott Baden wrote:

As request in the output for running "make  check"


These two issues on macOS will be fixed in the impending release (v8.32)
Specifically they were addressed by:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.31-93-gde73a867c

thanks,
Pádraig

bug#39879: Bug report

[Scott Baden]

As request in the output for running "make  check"
Attached

Scott Baden


test-suite.log.gz
Description: application/gzip

bug#37961: Bug report of date commond

[Paul Eggert]

On 10/28/19 12:34 AM, zhangzhi...@mail.iap.ac.cn wrote:

~>date  -d "1940-06-01" +"%Y-%m-%d"
date: invalid date ‘1940-06-01’


Presumably your TZ setting is Asia/Shanghai, as I see the symptoms as 
follows:


$ TZ=Asia/Shanghai date  -d "1940-06-01" +"%Y-%m-%d"
date: invalid date ‘1940-06-01’

This is because there is no instant of time 1940-06-01 00:00:00 in 
Shanghai, as the the clock ticked over from 1940-05-30 23:59:59 to 
1940-06-01 01:00:00 due to a daylight-saving time transition.


For this particular case, you'll have better luck with:

$ date -d "1940-06-01 12:00" +"%Y-%m-%d"

but this sort of approach does not work in general, because 12:00 does 
not always exist either. In other words, the 'date' command is not 
suited for calendrical arithmetic in general, only for time arithmetic.

bug#37961: Bug report of date commond

[zhangzhi...@mail.iap.ac.cn]

Mr. maintainers:
Hello! I am very glad to write this email to report my problem.
When I am running commond on my server： 

~>date  -d "1940-06-01" +"%Y-%m-%d"
date: invalid date ‘1940-06-01’

but the other commond works right：
sense3:~>date  -d '1939-06-01' +"%Y-%m-%d"
1939-06-01
sense3:~>date  -d '1940-06-02' +"%Y-%m-%d"
1940-06-02
sense3:~>date  -d '1940-05-31' +"%Y-%m-%d"
1940-05-31
sense3:~>date  -d '1940-07-02' +"%Y-%m-%d"
1940-07-02
sense3:~>date  -d '1940-07-01' +"%Y-%m-%d"
1940-07-01
sense3:~>date  -d '1940-05-01' +"%Y-%m-%d"
1940-05-01


my server's version and date version is：
~>uname -a
Linux zenglab 3.10.0-957.12.1.el7.x86_64 #1 SMP Mon Apr 29 14:59:59 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux
~>date --version
date (GNU coreutils) 8.22
Copyright (C) 2013 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 David MacKenzie.

This error makes my program woking wrong. Hope for your reply.

Thank you!






 张志敏 技术工程师
单位：中国科学院大气物理研究所 大气科学和地球流体力学数值模拟国家重点实验室（LASG）地址：中国北京市朝阳区德胜门外祁家豁子华严里40#，北京，100029 
 邮箱：zhangzhi...@mail.iap.ac.cn
电话：13391835740

bug#35636: bug report sort command

[Eric Blake]

tag 35636 notabug
thanks

On 5/8/19 3:35 AM, Michele Liberi wrote:
> I verified the following bug is there in:
> 
>- sort (GNU coreutils) 8.21
>- sort (GNU coreutils) 8.22
>- sort (GNU coreutils) 8.23
> 
> *Input file:*
> # cat sort.in
> 1|a|x
> 2|b|x
> 3|aa|x
> 4|bb|x
> 5|c|x
> 
> 
> *shell command and output:*
> # sort -t'|' -k2  3|aa|x
> 1|a|x
> 4|bb|x
> 2|b|x
> 5|c|x

Let's use --debug to see what sort really did:

$ sort --debug -t'|' -k2  
> *I expected that key "a" to come before key "aa" and key "b" to come before
> key "bb".*

Your expectations are at odds with your incomplete command line.  sort
is behaving as required; therefore, I'm closing this as not a bug. But
feel free to reply if you have further questions.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#35636: bug report sort command

[Michele Liberi]

I verified the following bug is there in:

   - sort (GNU coreutils) 8.21
   - sort (GNU coreutils) 8.22
   - sort (GNU coreutils) 8.23

*Input file:*
# cat sort.in
1|a|x
2|b|x
3|aa|x
4|bb|x
5|c|x


*shell command and output:*
# sort -t'|' -k2 

bug#34844: Bug report for coreutils

[冰柯]

Dear coreutils authors:
    Hi! I'm writing this to report a bug for `cp`. Actually I'm not sure if it 
is a bug, but it did something weird on my computer. Command `cp` creates 
hardlinks on the second call with `-u`.
The strange behavior was encountered when I tried to copy my files, in 
which there were a few hardlinks, into a FAT32 partition. At the first time, 
the command succeeded, and it then fails on the second call, 'cannot create 
hard link ..: Operation not permitted.'

Well, let's see a situation (first try on an ext4 partition, `cp` in 
version coreutils-8.28 is used):

    First create two directories `src` and `dst`:
        $ mkdir src dst
    Then create a regular file under `src`, and create a hardlink of it 
(`first` => `second`):
        $ touch src/first
        $ ln src/first src/second
Copy the files into `dst`:
$ cp -v -u src/* dst/
  'src/first' -> 'dst/first'
  'src/second' -> 'dst/second'
Using `ls` we can see the files under `src` are hardlinks, and files under 
`dst` are regular files:
$ ls -l src/
  total 0
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 14:59 first
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 14:59 second
$ ls -l dst/
  total 0
  -rw-rw-r-- 1 icyybk icyybk 0 Mar 13 15:03 first
  -rw-rw-r-- 1 icyybk icyybk 0 Mar 13 15:03 second
Then, run `cp` again:
$ cp -v -u src/* dst/
  removed 'dst/second'
$ ls -l dst/
  total 0
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 15:03 first
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 15:03 second
It appears that, during a second call, something weird happened, the two 
files under `dst` changed into hardlinks.
There's no error outputs in this situation, for the ext4 partition is used. 
But when a FAT32 partition is mounted on directory `dst`, the second call will 
fail with output:
  cp: cannot create hard link 'dst/second' to 'dst/first': Operation not 
permitted

Is there anything wrong with my commands? Hope not. I just felt strange 
about why they turned into hardlinks while in the first time they are regular 
files. Very sure I did not specify `--preserve=links`.
I'm now using version 8.28 of coreutils. It's the currently newest version 
I could download using my ubuntu 18.04 lts. Hope this bug will be fixed, if it 
is a bug.
Thanks for reading this email, and sorry for my 'not-very-good' English 
skills...
Have a nice day.

  Yours sincerely,
   Icy.

bug#34843: Bug report for coreutils-8.28 - `cp` creates hardlinks on the second call with `-u`

[冰柯]

Dear coreutils authors:
    Hi! I'm writing this to report a bug for `cp`. Actually I'm not sure if it 
is a bug, but it did something weird on my computer.
The strange behavior was encountered when I tried to copy my files, in 
which there were a few hardlinks, into a FAT32 partition. At the first time, 
the command succeeded, and it then fails on the second call, 'cannot create 
hard link ..: Operation not permitted.'

Well, let's see a situation (first try on an ext4 partition):

    First create two directories `src` and `dst`:
        $ mkdir src dst
    Then create a regular file under `src`, and create a hardlink of it 
(`first` => `second`):
        $ touch src/first
        $ ln src/first src/second
Copy the files into `dst`:
$ cp -v -u src/* dst/
  'src/first' -> 'dst/first'
  'src/second' -> 'dst/second'
Using `ls` we can see the files under `src` are hardlinks, and files under 
`dst` are regular files:
$ ls -l src/
  total 0
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 14:59 first
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 14:59 second
$ ls -l dst/
  total 0
  -rw-rw-r-- 1 icyybk icyybk 0 Mar 13 15:03 first
  -rw-rw-r-- 1 icyybk icyybk 0 Mar 13 15:03 second
Then, run `cp` again:
$ cp -v -u src/* dst/
  removed 'dst/second'
$ ls -l dst/
  total 0
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 15:03 first
  -rw-rw-r-- 2 icyybk icyybk 0 Mar 13 15:03 second
It appears that, during a second call, something weird happened, the two 
files under `dst` changed into hardlinks.
There's no error outputs in this situation, for the ext4 partition is used. 
But when a FAT32 partition is mounted on directory `dst`, the second call will 
fail with output:
  cp: cannot create hard link 'dst/second' to 'dst/first': Operation not 
permitted

Is there anything wrong with my commands? Hope not. I just felt strange 
about why they turned into hardlinks while in the first time they are regular 
files. Very sure I did not specify `--preserve=links`.
I'm now using version 8.28 of coreutils. It's the currently newest version 
I could download using my ubuntu 18.04 lts. Hope this bug will be fixed, if it 
is a bug.
Thanks for reading this email, and sorry for my 'not-very-good' English 
skills...
Have a nice day.

  Yours sincerely,
   Icy.

bug#33288: Bug report - tail: unrecognized file system type

[Assaf Gordon]

tags 33288 notabug
close 33288
stop

Hello,

On 2018-11-06 6:26 a.m., Adam Solymos wrote:

I have encountered an issue in tail command when running it in a Debian based 
Linux distro (Linux f596ea7f8fe0 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 
UTC 2018 x86_64 GNU/Linux) in a Docker container on a Windows 10 host OS.

Error message:
tail: unrecognized file system type 0xfe534d42 for 'errors.log'. please report 
this to bug-coreutils@gnu.org. reverting to polling


Thanks for the report.
This filesystem has been supported since version 8.26.
You are likely using an older version.

For details, see: https://www.gnu.org/software/coreutils/filesystems.html

regards,
 - assaf

bug#33288: Bug report - tail: unrecognized file system type

[Adam Solymos]

Hi,

I have encountered an issue in tail command when running it in a Debian based 
Linux distro (Linux f596ea7f8fe0 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 
UTC 2018 x86_64 GNU/Linux) in a Docker container on a Windows 10 host OS.

Error message:
tail: unrecognized file system type 0xfe534d42 for 'errors.log'. please report 
this to bug-coreutils@gnu.org. reverting to polling

Kind regards,

Adam Solymos
Software Developer

ESPC
Tel: 0131 624 8000
90a George Street, Edinburgh, EH2 3DF

Website | Facebook | 
Twitter | 
Instagram | 
LinkedIn




[http://assets.espc.com/sig/SHA_Finalist.png] 
[http://assets.espc.com/sig/SLA.png]
Private and Confidential: This e-mail transmission is strictly confidential and 
intended solely for the addressee. It may contain privileged and confidential 
information and if you are not the intended recipient, you must not copy, 
disclose, distribute or take any action in reliance on it. If you have received 
this e-mail in error, please delete it and notify our E-mail Systems 
Administrator on +44 (0) 131 624 8000. ESPC (UK) Ltd does not accept any 
liability for any harm that may be caused to the recipient's system or data by 
this message or any attachment.
ESPC (UK) Ltd is a company registered under the Companies Acts in Scotland 
(Registered Number SC203585), and having its registered office at 90A George 
Street, Edinburgh, Midlothian EH2 3DF.
ESPC (UK) Ltd is an Appointed Representative of Lyncombe Consultants Ltd which 
is authorised and regulated by the Financial Conduct Authority.

bug#29807: Probably ignore this bug report ;-)

[Assaf Gordon]

tags 29807 notabug
close 29807
stop

(triaging old bugs)

On 2017-12-21 9:45 p.m., Martin Schwenke wrote:

After reading the documentation again, I realise that it is actually
complete (i.e. no arguments implies --tmpdir).


Given the above, I'm closing this bug.


[...] A separate discussion of TMPDIR would be more helpful.


Patches and wording suggestions are always welcomed.

regards,
 - assaf

bug#27640: Bug-report

[Assaf Gordon]

tags 27640 fixed
close 27640
stop

(triaging old bugs)

On 2017-07-10 1:08 p.m., Paul Eggert wrote:
Looking at that test's source code, the test was clearly incorrect for 
Unix-like systems, as it incorrectly assumed a 1-1 mapping between user 
names and user IDs. I fixed that in Gnulib by installing the attached 
patch.


Pushed to gnulib here:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=24605b2f03bfa8367a9149835c687c9073aacc2c

So closing as "fixed".

-assaf

bug#27531: Coreutils 8.27 bug report

[Assaf Gordon]

tags 27531 moreinfo
close 27531
stop

(triaging old bugs)

On 2017-07-10 10:51 a.m., Pádraig Brady wrote:

On 29/06/17 06:32, Bernardo Lopes Almeida de Oliveira wrote:


Please find attached the test-suite.log.


The seq failure though is due to your system not behaving like:

   $ src/seq inf inf | head -n2
   inf
   inf

What architecture and c library do you use?



With no further follow-ups in more than a year,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#23268: sort ant uniq bug report

[Assaf Gordon]

tags 23268 notabug
close 23268

(triaging old bugs)

On 2016-04-11 11:56 a.m., Assaf Gordon wrote:


On 04/11/2016 12:43 PM, 126 wrote:
Every other input is working well,but when my input contain several 
lines of "src/table/checkpoint/checkPointInfo5000.lua". The result of 
(sort -u) contain two lines of 
"src/table/checkpoint/checkPointInfo5000.lua"


Without seeing the exact input, it is hard to diagnose the issue.

Please attach a *small* input file, with the exact command that 
reproduces your situation to help us understand what's going on.


With no further follow-ups in 2 years, I'm closing this bug.

-assaf

bug#31235: Bug Report Google Cloud - App Engine Deploy

[Bernhard Voelker]

On 04/22/2018 04:54 AM, Travis Sperry wrote:
> tail: unrecognized file system type 0x794c7630 for '/tmp/cloud_sql_proxy.log’
> 
> Travis Sperry


Please update.  Your version of coreutils is more than 2 years old.
Support for this file system type has been added in later versions
of coreutils (8.25 and later). For details see here:
https://www.gnu.org/software/coreutils/filesystems.html

Have a nice day,
Berny

bug#31235: Bug Report Google Cloud - App Engine Deploy

[Travis Sperry]

tail: unrecognized file system type 0x794c7630 for '/tmp/cloud_sql_proxy.log’

Travis Sperry
travis.sper...@gmail.com

bug#29069: Fwd: Fwd: Re: bug#29069: info coreutils file permissions: improvements/bug-report

[kalle]

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


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

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

greetings,
kalle

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

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

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

bug#30482: Bug report

[Bernhard Voelker]

unarchive 22151
forcemerge 22151 30482
stop

On 02/16/2018 03:12 AM, Mail.sbo.tech wrote:

Tail: unrecognized file system type 0x794c7630 for ‘/var/log/mail...


Thanks, this is already fixed in coreutils >= 8.25 ... and we're now
at 8.29.  See also:
   https://www.gnu.org/software/coreutils/filesystems.html

Have a nice day,
Berny

bug#30482: Bug report

[Mail.sbo.tech]

Tail: unrecognized file system type 0x794c7630 for ‘/var/log/mail...

Sent from my iPhone

bug#29069: Fwd: Re: bug#29069: info coreutils file permissions: improvements/bug-report

[kalle]

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

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

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

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

bug#29069: info coreutils file permissions: improvements/bug-report

[kalle]

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

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

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

Is that enough?

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

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

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

diff --git a/doc/perm.texi b/doc/perm.texi
index c94c483..a514998 100644
--- a/doc/perm.texi
+++ b/doc/perm.texi
@@ -491,59 +491,25 @@ the file to all users.
 @cindex numeric modes
 @cindex file mode bits, numeric
 @cindex octal numbers for file modes
-As an
-alternative to giving a symbolic mode, you can give an octal (base 8)
-number that represents the mode.
-This number is always interpreted in octal; you do not have to add a
-leading @samp{0}, as you do in C.  Mode @samp{0055} is the same as
-mode @samp{55}.  (However, modes of five digits or more, such as
-@samp{00055}, are sometimes special.  @xref{Directory Setuid and Setgid}.)
-
-A numeric mode is usually shorter than the corresponding symbolic
-mode, but it is limited in that normally it cannot take into account the
-previous file mode bits; it can only set them absolutely.
-The set-user-ID and set-group-ID bits of directories are an exception
-to this general limitation.  @xref{Directory Setuid and Setgid}.
-Also, operator numeric modes can take previous file mode bits into
-account.  @xref{Operator Numeric Modes}.
-
-The permissions granted to the user,
-to other users in the file's group,
-and to other users not in the file's group each require three
-bits, which are represented as one octal digit.  The three special
-mode bits also require one bit each, and they are as a group
-represented as another octal digit.  Here is how the bits are arranged,
-starting with the lowest valued bit:
+As an alternative to giving a symbolic mode, you can give an octal (with base 
8) number that represents the mode.This number is always interpreted in octal; 
you do not have to add a leading @samp{0}, as you do in C. Mode @samp{0055} is 
the same as mode @samp{55}.  Modes of five digits or more, such as 
@samp{00055}, have a special meaning for directories  @xref{Directory Setuid 
and Setgid}.)
+
+A numeric mode is usually shorter than the corresponding symbolic mode, but it 
is limited in that normally it cannot take into account the previous file mode 
bits; it can only set them absolutely.  The set-user-ID and set-group-ID bits 
of directories are an exception to this general limitation.   @xref{Directory 
Setuid and Setgid}.  Also, operator numeric modes can take previous file mode 
bits into account.  @xref{Operator Numeric Modes}.
+
+The octal notation can be derived from the symbolic one, as an intermediate 
step transforming it into a binary string (1), which is then easily changed 
into octal base (2):
+
+(1)For the intermediate step the @samp{r},@samp{w} and @samp{x}-symbols of the 
symbolic notation are changed out at the corresponding place by a @samp{0} or a 
@samp{1}, according to whether the bits are clear or set  (this works as long 
as there are no special mode bits, because every place belongs specifically to 
one kind of bit), thus transforming e.g. the string @samp{rwxr-xr--} into 
@samp{01100}.Then instead of overriding the @samp{x}-bits, the special mode 
bits are represented by grouping them at the be

bug#29807: Probably ignore this bug report ;-)

[Martin Schwenke]

After reading the documentation again, I realise that it is actually
complete (i.e. no arguments implies --tmpdir).

I would, however, regard the documentation to be structured in a way
that makes it hard to find the information about TMPDIR.  That is,
searching for TMPDIR doesn't find the answer.  You need to carefully
read that no arguments implies --tmpdir and that this implies the use
of TMPDIR.  A separate discussion of TMPDIR would be more helpful.

Thanks...

peace & happiness,
martin

bug#29069: info coreutils file permissions: improvements/bug-report

[kalle]

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

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

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

greetings,
kalle

bug#29069: info coreutils file permissions: improvements/bug-report

[kalle]

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



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

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

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

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

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

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

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

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

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

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

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



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

>Any category.

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

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


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

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

Where else would be the place to write about this?

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

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


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

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

No native English speakers answering...


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

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

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

>In GNU's chmod(1), setting the 4th digit to zero *does not* clear those
bits, it preserves them (i.e. does not change them if they are se

bug#29164: Scratch this bug report

[Jim Meyering]

tags 29164 notabug
thanks

On Mon, Nov 6, 2017 at 12:21 AM, Thomas Deutschmann  wrote:
> please ignore this bug report. This is caused by Gentoo's sandbox in
> portage and no problem in coreutils. Sorry for wasting your time :/

Closing and marking as notabug

bug#29164: Scratch this bug report

[Thomas Deutschmann]

Hi,

please ignore this bug report. This is caused by Gentoo's sandbox in
portage and no problem in coreutils. Sorry for wasting your time :/


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

bug#29069: info coreutils file permissions: improvements/bug-report

[Assaf Gordon]

tag 29069 notabug
stop

Hello,

On 2017-10-30 02:38 PM, kalle wrote:
here some improvement proposals/bug report on info coreutils file 
permissions:


-in my opinion it would be good to explain the general idea bihind 
the file permissions a bit more. what the issues are etc. Elese one 
doesn't really understand, what all the detailed fuss is about. -why

is running a file considered different  from reading one? Fact is,
that this point underlies the concept of symbolic mode with it's 
`rwx'. -


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

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

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


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


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

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

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


Any category.

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

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


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


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

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

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



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


(I'll leave this to native English speakers)

> -27.3: is there an info/man-document, where binary,
octal, hex-numbers are explained? If, it should be referred to. If 
not, shouldn't there be one (and where would it fit in? ) ?-- I

could write the text...Since this documentation assumes the knowledge
of it..


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


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


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

>
-27.5: it is said, that "a command like `chmod' does not

affect the set-user-id, unless […] sets them in a numeric mode".But
also, the example states that `chmod 0755' or `mkdir -m 0755'
doesn't change set-user/group-id- bits.

>
For me, this doesn't fit 
together,since the `0' in `0755' explicitly sets all special mode 
bits to zero.


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


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


In GNU's chmod(1), setting the 4th digit to zero *does not* clear those 
bits, it preserves them (i.e. does not change them if they are set).

To clear them, one needs to specify *five* octal digits: 00755.

This is explained in the second paragraph of section 27.5:
"Therefore, a command like chmod does not affect the set-user-ID or 
set-group-ID bits of a directory unless the user specifically mentions 
them in a symbolic mode, or uses an operator numeric mode such as 
‘=755’, or sets them in a numeric mode, or clears them in a numeric mode 
that has **five or more** octal digits."

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

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


The wording could also be improved in section "27.3 Numeric Modes", 
which only mentions this in p

bug#29069: info coreutils file permissions: improvements/bug-report

[kalle]

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

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

greetings,
kalle

bug#28929: Bug report for tail

[Dmitry V. Levin]

merge 28929 28970 29022
tag 28929 notabug
thanks

On Sat, Oct 21, 2017 at 02:47:03PM -0400, Mohammad Edghaim wrote:
[...]
> "unrecognized file system type 0x794c7630 for 'xyz.log'. please report this
> to bug-coreutils@gnu.org. reverting to polling"
[...]
On Tue, Oct 24, 2017 at 09:33:56AM -0700, Brad Lowe wrote:
[...]
> tail: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’.
> please report this to bug-coreutils@gnu.org. reverting to polling
[...]
On Thu, Oct 26, 2017 at 07:42:42PM -0400, Gustavo Frederico wrote:
[...]
> tail: unrecognized file system type 0x794c7630 for 
> '/u01/app/oracle/diag/tnslsnr/e7bd4e34ce20/listener/alert/log.xml'. please 
> report this to bug-coreutils@gnu.org. reverting to polling

tail in coreutils >= 8.25 no longer warns about unrecognized file systems
and does not prompt the user to email with the unrecognized constant.


-- 
ldv

bug#28929: Bug report for tail

[Mohammad Edghaim]

Hello,

I got the following message trying to tail a file:

"unrecognized file system type 0x794c7630 for 'xyz.log'. please report this
to bug-coreutils@gnu.org. reverting to polling"

The debug message said please!

Specs:
Windows 7, running VirtualBox VM with an arch linux install, running kernel
4.11.3-1-ARCH

But just to go deeper, I only get this issue when I tail a log inside a
docker container I run in arch.

bug#28775: 回复: Re: bug#28775: bug report

[Bernhard Voelker]

[ please don't top-post on technical lists]

On 10/11/2017 04:09 AM, cheng...@zhongan.com wrote:
> On 2017-10-10 20:36, Bernhard Voelker wrote:
>> This is an 'overlayfs' file system - this issue is already fixed since 
>> coreutils-8.25
>> (and now we're at 8.28).
>  
> It's the latest version, but it's still a bug#28775 problem.

We're only the upstream project (where the issue is fixed) which cares about
the sources only.  You have to contact your downstream distributor which is
providing you the binary executables to upgrade to a newer version ... in
this case the distributor of XShell5.

P.S. please do not send such big screenshot images to this GNU mailing list,
as this a) wastes bandwidth in general (because it is sent to each recipient),
and b) some recipients do not have such a good/cheap internet connection.
Instead, you could have pasted the images to some server and just given us
the link to it.  Thanks.

Have a nice day,
Bernhard Voelker

bug#28775: bug report

[Bernhard Voelker]

On 10/10/2017 05:15 AM, cheng...@zhongan.com wrote:
> [root@HZD-T-QA-TEST-31 logs]# tail -fn 200 
> gwhttp-ss_regular_app_gatewayhttp_it_info.log | grep '32d192102a90'
> tail: unrecognized file system type 0x794c7630 for 
> ‘gwhttp-ss_regular_app_gatewayhttp_it_info.log’. please report this to 
> bug-coreutils@gnu.org. reverting to polling

This is an 'overlayfs' file system - this issue is already fixed since 
coreutils-8.25
(and now we're at 8.28).

Have a nice day,
Berny

bug#28775: bug report

[cheng...@zhongan.com]

[root@HZD-T-QA-TEST-31 logs]# tail -fn 200 
gwhttp-ss_regular_app_gatewayhttp_it_info.log | grep '32d192102a90'
tail: unrecognized file system type 0x794c7630 for 
‘gwhttp-ss_regular_app_gatewayhttp_it_info.log’. please report this to 
bug-coreutils@gnu.org. reverting to polling

bug#27640: Bug-report

[Paul Eggert]

Looking at that test's source code, the test was clearly incorrect for 
Unix-like systems, as it incorrectly assumed a 1-1 mapping between user 
names and user IDs. I fixed that in Gnulib by installing the attached 
patch. Wolfgang, could you please try this on your Linux from Scratch 
system? You can do that by downloading these two files:


http://git.savannah.gnu.org/cgit/gnulib.git/plain/tests/test-getlogin.c
http://git.savannah.gnu.org/cgit/gnulib.git/plain/tests/test-getlogin_r.c

Use the first to replace the existing test-getlogin.c in your coreutils 
source directory, and put the second next to the first.


>From 237ea098c82e141713964931f96a37fa6d6cda12 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 10 Jul 2017 11:56:48 -0700
Subject: [PATCH] =?UTF-8?q?getlogin:=20don=E2=80=99t=20assume=20one=20name?=
 =?UTF-8?q?=20per=20uid?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Wolfgang F. Muthmann (Bug#27640).
* modules/getlogin-tests (Files): Add tests/test-getlogin_r.c.
(ttyname): Remove test.
* modules/getlogin_r-tests (ttyname): Remove test.
* tests/test-getlogin.c: Replace this near-clone of test-getlogin_r.c
with ‘#define TEST_LOGIN’ followed by ‘#include "test-getlogin_r.c"’.
* tests/test-getlogin_r.c: If TEST_GETLOGIN is defined, test
getlogin rather than getlogin_r.  This avoids code duplication.
(main): Use isatty and fstat rather than ttyname and stat.
Use getpwnam instead of getpwuid, to be portable to test platforms
that have multiple login names for the same uid.
---
 ChangeLog|  15 +++
 modules/getlogin-tests   |   2 +-
 modules/getlogin_r-tests |   1 -
 tests/test-getlogin.c| 112 +--
 tests/test-getlogin_r.c  |  35 +--
 5 files changed, 39 insertions(+), 126 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index af99a9c..e5bfb7e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2017-07-10  Paul Eggert  
+
+	getlogin: don’t assume one name per uid
+	Problem reported by Wolfgang F. Muthmann (Bug#27640).
+	* modules/getlogin-tests (Files): Add tests/test-getlogin_r.c.
+	(ttyname): Remove test.
+	* modules/getlogin_r-tests (ttyname): Remove test.
+	* tests/test-getlogin.c: Replace this near-clone of test-getlogin_r.c
+	with ‘#define TEST_LOGIN’ followed by ‘#include "test-getlogin_r.c"’.
+	* tests/test-getlogin_r.c: If TEST_GETLOGIN is defined, test
+	getlogin rather than getlogin_r.  This avoids code duplication.
+	(main): Use isatty and fstat rather than ttyname and stat.
+	Use getpwnam instead of getpwuid, to be portable to test platforms
+	that have multiple login names for the same uid.
+
 2017-07-10  Tim Rühsen  
 Bruno Haible  
 
diff --git a/modules/getlogin-tests b/modules/getlogin-tests
index c8cdb05..d7d6aea 100644
--- a/modules/getlogin-tests
+++ b/modules/getlogin-tests
@@ -1,12 +1,12 @@
 Files:
 tests/test-getlogin.c
+tests/test-getlogin_r.c
 tests/signature.h
 tests/macros.h
 
 Depends-on:
 
 configure.ac:
-AC_CHECK_FUNCS_ONCE([ttyname])
 
 Makefile.am:
 TESTS += test-getlogin
diff --git a/modules/getlogin_r-tests b/modules/getlogin_r-tests
index 868b1b6..845658f 100644
--- a/modules/getlogin_r-tests
+++ b/modules/getlogin_r-tests
@@ -6,7 +6,6 @@ tests/macros.h
 Depends-on:
 
 configure.ac:
-AC_CHECK_FUNCS_ONCE([ttyname])
 
 Makefile.am:
 TESTS += test-getlogin_r
diff --git a/tests/test-getlogin.c b/tests/test-getlogin.c
index 86b2a9e..6a6d269 100644
--- a/tests/test-getlogin.c
+++ b/tests/test-getlogin.c
@@ -1,110 +1,2 @@
-/* Test of getting user name.
-   Copyright (C) 2010-2017 Free Software Foundation, Inc.
-
-   This program is free software: you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 3 of the License, or
-   (at your option) any later version.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   You should have received a copy of the GNU General Public License
-   along with this program.  If not, see .  */
-
-/* Written by Bruno Haible , 2010.  */
-
-#include 
-
-#include 
-
-#include "signature.h"
-SIGNATURE_CHECK (getlogin, char *, (void));
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#if !((defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__)
-# include 
-#endif
-
-#include 
-#include 
-
-#include "macros.h"
-
-int
-main (void)
-{
-  char *buf;
-
-  /* Test value.  */
-  buf = getlogin ();
-  if (buf == NULL)
-{
-  if (errno == ENOENT)
-{
-  /* This can happen on GNU/Linux.  */
-  fprintf (stderr, "Skipping test: no entry in utmp file.\n");
-  return 77;
-}
-
-  

bug#27640: Bug-report

[Bruno Haible]

Regarding https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27640 :

Hello Wolfgang,

What type of system is this? You are saying "Linux From Scratch version 8.0".
What type of libc is it using? There are several competing ones [1].

> > FAIL: test-getlogin
> > ===
> > 
> > test-getlogin.c:92: assertion 'strcmp (pwd->pw_name, buf) == 0' failed
> > FAIL test-getlogin (exit status: 134)

Please run the 'test-getlogin' program with ltrace (or, alternatively,
insert printf statements that show what's going on). I get (in a regular
login, or with sudo):

$ ltrace ./test-getlogin
__libc_start_main(0x400b46, 1, 0x7ffef8724a78, 0x403db0 
getlogin()  
 = "bruno"
ttyname(0)  
 = "/dev/pts/13"
__xstat(1, "/dev/pts/13", 0x7ffef87248f0)   
 = 0
getpwuid(1000, 0x7ffef87248f0, 0x7ffef87248f0, 0x7f3d50d1abb5)  
 = 0x7f3d50feadc0
strcmp("bruno", "bruno")
 = 0
+++ exited (status 0) +++

What are the results for you?

What else, that affects the operation of getlogin(), ttyname(), getpwuid(),
could be special in your environment?

Bruno

[1] http://www.etalabs.net/compare_libcs.html

bug#27640: Bug-report

[Pádraig Brady]

On 10/07/17 00:46, Wolfgang F. Muthmann wrote:
> FAIL: test-getlogin
> ===
> 
> test-getlogin.c:92: assertion 'strcmp (pwd->pw_name, buf) == 0' failed
> FAIL test-getlogin (exit status: 134)

Forwarding to gnulib

thanks,
Pádraig

bug#27531: Coreutils 8.27 bug report

[Pádraig Brady]

On 29/06/17 06:32, Bernardo Lopes Almeida de Oliveira wrote:
> Dear all,
> 
> Please find attached the test-suite.log.

The date false failure is already fixed I think.

The seq failure though is due to your system not behaving like:

  $ src/seq inf inf | head -n2
  inf
  inf

What architecture and c library do you use?

thanks,
Pádraig

bug#27640: Bug-report

[Wolfgang F. Muthmann]

Hi, I just encountered the following report during generation of Linux
>From Scratch version 8.0 :
doing: "make RUN_EXPENSIVE_TESTS=yes check"


Testsuite summary for GNU coreutils 8.26

# TOTAL: 311
# PASS:  276
# SKIP:  34
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See gnulib-tests/test-suite.log
Please report to bug-coreutils@gnu.org


=
   GNU coreutils 8.26: gnulib-tests/test-suite.log
=

# TOTAL: 311
# PASS:  276
# SKIP:  34
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: test-set-mode-acl.sh
==

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-set-mode-acl.sh (exit status: 77)

SKIP: test-set-mode-acl-1.sh


+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-set-mode-acl-1.sh (exit status: 77)

SKIP: test-set-mode-acl-2.sh


+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-set-mode-acl-2.sh (exit status: 77)

SKIP: test-copy-acl.sh
==

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-copy-acl.sh (exit status: 77)

SKIP: test-copy-acl-1.sh


+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-copy-acl-1.sh (exit status: 77)

SKIP: test-copy-acl-2.sh


+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-copy-acl-2.sh (exit status: 77)

SKIP: test-btowc1.sh


Skipping test: no traditional french locale is installed
SKIP test-btowc1.sh (exit status: 77)

SKIP: test-btowc2.sh


Skipping test: no french Unicode locale is installed
SKIP test-btowc2.sh (exit status: 77)

SKIP: test-file-has-acl.sh
==

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-file-has-acl.sh (exit status: 77)

SKIP: test-file-has-acl-1.sh


+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-file-has-acl-1.sh (exit status: 77)

SKIP: test-file-has-acl-2.sh


+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-file-has-acl-2.sh (exit status: 77)

FAIL: test-getlogin
===

test-getlogin.c:92: assertion 'strcmp (pwd->pw_name, buf) == 0' failed
FAIL test-getlogin (exit status: 134)

SKIP: test-mbrtowc1.sh
==

Skipping test: no traditional french locale is installed
SKIP test-mbrtowc1.sh (exit status: 77)

SKIP: test-mbrtowc2.sh
==

Skipping test: no french Unicode locale is installed
SKIP test-mbrtowc2.sh (exit status: 77)

SKIP: test-mbrtowc3.sh
==

Skipping test: no traditional japanese locale is installed
SKIP test-mbrtowc3.sh (exit status: 77)

SKIP: test-mbrtowc4.sh
==

Skipping test: no transitional chinese locale is installed
SKIP test-mbrtowc4.sh (exit status: 77)

SKIP: test-mbrtowc-w32-1.sh
===

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-1.sh (exit status: 77)

SKIP: test-mbrtowc-w32-2.sh
===

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-2.sh (exit status: 77)

SKIP: test-mbrtowc-w32-3.sh
===

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-3.sh (exit status: 77)

SKIP: test-mbrtowc-w32-4.sh
===

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-4.sh (exit status: 77)

SKIP: test-mbrtowc-w32-5.sh
===

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-5.sh (exit status: 77)

SKIP: test-mbscasecmp.sh


Skipping test: no turkish Unicode locale is installed
SKIP test-mbscasecmp.sh (exit status: 77)

SKIP: test-mbsinit.sh
=

Skipping test: no french Unicode locale is installed
SKIP test-mbsinit.sh (exit status: 77)

SKIP: test-

bug#25806: Bug Report

[Brinkley Harrell]

Thanks for the info — this is in the Windows 10 Tools for Linux and the version 
was current available stream ver 1607. I will try it in the Creator’s Preview 
builds on the Insider Fast Track and, if it is still a problem there, I will 
report it to Microsoft.
Brinkley Harrell
jbharr...@fusemeister.com



> On Feb 19, 2017, at 7:12 PM, Pádraig Brady  wrote:
> 
> unarchive 23273
> forcemerge 23273 25806
> close 25806
> stop
> 
> On 19/02/17 14:47, jbharr...@fusemeister.com wrote:
>> jharrell@PECOS:~/backup-info$ tail -f
>> backup-2017-02-19_16\:41\:26_STD.txt
>> total size is 49,485,587  speedup is 21,075.63
>> sending incremental file list
>> Shared/ 
>> sent 59 bytes  received 20 bytes  158.00 bytes/sec
>> total size is 0  speedup is 0.00
>> sending incremental file list
>> CentOS-65-x64/
>> CentOS-65-x64/CentOS-65-x64-0-02.vmdk
>> CentOS-65-x64/CentOS-65-x64-0.vmdk
>> tail: unrecognized file system type 0x53464846 for
>> 'backup-2017-02-19_16:41:26_STD.txt'. please report this to
>> bug-coreutils@gnu.org. reverting to polling 
>> 
>> System is Windows 10 Professional,
>> 
> 
> Thanks for the report, however, the fix is already available
> in a newer release (v8.26).

bug#25806: Bug Report

[Pádraig Brady]

unarchive 23273
forcemerge 23273 25806
close 25806
stop

On 19/02/17 14:47, jbharr...@fusemeister.com wrote:
> jharrell@PECOS:~/backup-info$ tail -f
> backup-2017-02-19_16\:41\:26_STD.txt
> total size is 49,485,587  speedup is 21,075.63
> sending incremental file list
> Shared/ 
> sent 59 bytes  received 20 bytes  158.00 bytes/sec
> total size is 0  speedup is 0.00
> sending incremental file list
> CentOS-65-x64/
> CentOS-65-x64/CentOS-65-x64-0-02.vmdk
> CentOS-65-x64/CentOS-65-x64-0.vmdk
> tail: unrecognized file system type 0x53464846 for
> 'backup-2017-02-19_16:41:26_STD.txt'. please report this to
> bug-coreutils@gnu.org. reverting to polling 
> 
> System is Windows 10 Professional,
> 

Thanks for the report, however, the fix is already available
in a newer release (v8.26).

bug#25806: Bug Report

[jbharrell]

jharrell@PECOS:~/backup-info$ tail -f
backup-2017-02-19_16\:41\:26_STD.txt
total size is 49,485,587  speedup is 21,075.63
sending incremental file list
Shared/ 
sent 59 bytes  received 20 bytes  158.00 bytes/sec
total size is 0  speedup is 0.00
sending incremental file list
CentOS-65-x64/
CentOS-65-x64/CentOS-65-x64-0-02.vmdk
CentOS-65-x64/CentOS-65-x64-0.vmdk
tail: unrecognized file system type 0x53464846 for
'backup-2017-02-19_16:41:26_STD.txt'. please report this to
bug-coreutils@gnu.org. reverting to polling 

System is Windows 10 Professional,

bug#25516: Ubuntu on Windows bug report

[Pádraig Brady]

unarchive 23273
forcemerge 23273 25516
close 25516
stop

On 24/01/17 07:44, Franklin wrote:
> I was initiating a "tail -f" on a log file of a hamradio digital app, WSJT-X .
> 
> 
> --
> 
> tail: unrecognized file system type 0x53464846 for 'wsjtx.log'. please report 
> this to bug-coreutils@gnu.org. reverting to polling
> 
> --
> 
> 
> Pass along a link to the bug tracker and I'll submit the bug myself.

This is already fixed in a released version.

thanks,
Pádraig

bug#25516: Ubuntu on Windows bug report

[Franklin]

I was initiating a "tail -f" on a log file of a hamradio digital app, WSJT-X .


--

tail: unrecognized file system type 0x53464846 for 'wsjtx.log'. please report 
this to bug-coreutils@gnu.org. reverting to polling

--


Pass along a link to the bug tracker and I'll submit the bug myself.


thanx

-frank

Franklin Boots

610-588-1042


Sent from my MacBook

bug#23268: sort ant uniq bug report

[Assaf Gordon]

(adding debbugs mailing list)

Hello,

On 04/11/2016 12:43 PM, 126 wrote:

Thank you for your reply.
I'm sorry for not describe my problem clearly.
Every other input is working well,but when my input contain several lines of 
"src/table/checkpoint/checkPointInfo5000.lua". The result of (sort -u) contain two lines 
of "src/table/checkpoint/checkPointInfo5000.lua"


Without seeing the exact input, it is hard to diagnose the issue.

Please attach a *small* input file, with the exact command that reproduces your 
situation to help us understand what's going on.
(I highly recommend attaching a file and not copy-pasting to avoid any issues 
caused by the mail program).

regards,
 - assaf

bug#23268: sort ant uniq bug report

[Assaf Gordon]

tag 23268 notabug
close 23268
thanks

Hello,

On 04/11/2016 06:49 AM, 126 wrote:

hello, Gentleman
when I use sort and uniq, and input like this below, I got wrong output:

[...]

"|sort -u

[...]

no result when I use `uniq -u`


This is due to wrong usage of 'uniq -u'.

The meaning of '-u' in 'uniq' is subtly different than '-u' in 'sort':

In 'sort', it means "print each line once" i.e. removing duplicates.
In 'uniq', it means "print only unique lines" i.e. lines which appear only once.

The equivalent of 'sort -u' is 'sort|uniq'.

Since all lines in your input had duplicates, 'uniq -u' printed none.

The following will demonstrate:

$ printf "a\nb\na\nc\nb\n"
a
b
a
c
b

$ printf "a\nb\na\nc\nb\n" | sort -u
 a
b
c

$ printf "a\nb\na\nc\nb\n" | sort | uniq
a
b
c

$ printf "a\nb\na\nc\nb\n" | sort | uniq -u
c


As such I'm closing this bug, but discussion can continue by replying to this 
thread.
regards,
 - assaf

bug#23268: sort ant uniq bug report

[126]

hello, Gentleman
when I use sort and uniq, and input like this below, I got wrong output:

$ echo "src/scenelayer/actSceneTipLayer.lua
> src/table/checkpoint/checkPointInfo5000.lua
> src/table/checkpoint/checkPointInfo5000.lua 
> src/table/fightscenecheckpoint.lua
> src/scenelayer/actSceneTipLayer.lua
> src/table/checkpoint/checkPointInfo5000.lua
> src/table/checkpoint/checkPointInfo5000.lua 
> src/table/fightscenecheckpoint.lua
> "|sort -u

src/scenelayer/actSceneTipLayer.lua
src/table/checkpoint/checkPointInfo5000.lua
src/table/checkpoint/checkPointInfo5000.lua 
src/table/fightscenecheckpoint.lua

no result when I use `uniq -u`
$ echo "src/scenelayer/actSceneTipLayer.lua
src/table/checkpoint/checkPointInfo5000.lua
src/table/checkpoint/checkPointInfo5000.lua 
src/table/fightscenecheckpoint.lua
src/scenelayer/actSceneTipLayer.lua
src/table/checkpoint/checkPointInfo5000.lua
src/table/checkpoint/checkPointInfo5000.lua 
src/table/fightscenecheckpoint.lua
"|sort| uniq -u


It appear the same on CentOS, Cygwin , and Mac OS X
I wonder whether it's my own mistake or the program goes wrong.

bug#23176: Bug report / tail / ubuntu 14.04.2 LTS /

[Pádraig Brady]

forcemerge 23143 23176
close 23176
stop

On 01/04/16 08:55, Bernhard Voelker wrote:

Thanks for the report, but I'm afraid the PNGs attached to [0]
are not readable:

The image "..." cannot be displayed because it contains errors.

[0] http://bugs.gnu.org/23176


stored pngs are mangled for me also, though I received
the moderator email too where they were OK and confirmed
that this is the same "prl_fs" issue as recently fixed.

thanks,
Pádraig.

bug#23176: Bug report / tail / ubuntu 14.04.2 LTS /

[Bernhard Voelker]

On 03/31/2016 11:51 PM, Eric Blake wrote:

[moderator note - resending with large .pngs stripped so as not to
overwhelm the list server or recipients; the original bug can be viewed
online at bugs.gnu.org/23176]


 Forwarded Message 
To: 23...@debbugs.gnu.org
Date: Thu, 31 Mar 2016 20:55:58 +0200
Message-ID:

From: Hamed OUARET 

Hi,

I want to report a bug, as suggested by the message I got
(see screen shot attached).

*My configuration as follow :*
Ubuntu : 14.04.2.LTS, running into as Virtual Machine
[ under Parallels Desktop Version 10.3.0 (29227) ] into a Mac.
(see full description hereto below)

The file I am tailing is a {log output } of a [ wget -m ] command.
Should you need more information, please let me know.


From Paris, with Love !

Hamed


Thanks for the report, but I'm afraid the PNGs attached to [0]
are not readable:

  The image "..." cannot be displayed because it contains errors.

[0] http://bugs.gnu.org/23176

From the above text, it's totally unclear to me what the problem is,
what the actual commands were you ran, what the output was, and what
you expected instead, etc.

Please give us more - with copy/paste-able text instead of screenshots
if possible.

Thanks & have a nice day,
Berny

bug#23176: Bug report / tail / ubuntu 14.04.2 LTS /

[Eric Blake]

[moderator note - resending with large .pngs stripped so as not to
overwhelm the list server or recipients; the original bug can be viewed
online at bugs.gnu.org/23176]


 Forwarded Message 
To: 23...@debbugs.gnu.org
Date: Thu, 31 Mar 2016 20:55:58 +0200
Message-ID:

From: Hamed OUARET 

Hi,

I want to report a bug, as suggested by the message I got
(see screen shot attached).

*My configuration as follow :*
Ubuntu : 14.04.2.LTS, running into as Virtual Machine
[ under Parallels Desktop Version 10.3.0 (29227) ] into a Mac.
(see full description hereto below)

The file I am tailing is a {log output } of a [ wget -m ] command.
Should you need more information, please let me know.

>From Paris, with Love !
Hamed


[image: Inline image 1]



[image: Inline image 2]






signature.asc
Description: OpenPGP digital signature

bug#22393: bug report - file system type unrecognized

[Pádraig Brady]

forcemerge 22393 22151
close 22151
stop

On 17/01/16 15:37, Chanan Berler wrote:
> Hello,
> 
>  
> 
> While running WSO2 identity server example inside docker container – I got 
> this error message asking me to report the bug.
> 
> tail: unrecognized file system type 0x794c7630

The fix will be in the upcoming v8.25 release:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-111-g1118f32

thanks,
Pádraig

bug#22393: bug report - file system type unrecognized

[Chanan Berler]

Hello,

While running WSO2 identity server example inside docker container - I got this 
error message asking me to report the bug.
So here is the message:

tail: unrecognized file system type 0x794c7630 for 'manager.2016-01-17.log'. 
please report this to bug-coreutils@gnu.org. reverting to polling

Enjoy
Chanan
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

bug#19329: Bug report

[throwaway1024]

 


Thanks for your elaborate response.

 

I'm just a beginner with GNU/Linux. I know my terminal code is more
like a patch work and doesn't look that professional yet.


I shortened valbug.txt only to the lines around the (apparent) bugs
with Gedit and looked at the edited file in a hexviewer. There was no
\r\n visible (just \n) and all the duplicate lines looked the same to
the byte.

 

I expected, that Gedit would NOT change the line endings or it would
at least tell me, that it did. That's where I went wrong.

 

Next time I'll use grep and od to verify it directly in the terminal
such that no unexpected conversions with the line endings can happen.

 

>Also, it appears that the data you posted may have used some sort of
>simple substitution cypher
These are some artificial city names for an exercise and it is/looks
likely that substitution on real names was used to generate them.

 

bug#18568: Bug Report test-getlogin failed

[Pádraig Brady]

On 09/26/2014 07:24 AM, Sorawit Khurnyotrak wrote:
> FAIL: test-getlogin
> ===
> test-getlogin.c:69: assertion 'strcmp (buf, name) == 0' failed

Thanks for the report.
I'm fairly sure that has been fixed up in coreutils-8.23
the recent changes in that gnulib test, specifically:

http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=97249cf

thanks,
Pádraig.

bug#18568: Bug Report test-getlogin failed

[Sorawit Khurnyotrak]

Dear Sir,
  While i compile coreutils-8.22 with LFS i get this error ,
Please correct me.

Best regards,


error.log
Description: Binary data


test-suite.log
Description: Binary data

bug#18503: [bug-report] the output of ls -lsh

[Gemfield]

Yes, it is exactly same as bug#17838. Is -lsh  makes me have a misunderstanding 
that this file has a size of 4.0K blocks (4000*1024B)
.
Thanks.

发自Gemfield 的 iPhone

> 在 2014年9月19日，上午8:41，Pádraig Brady  写道：
> 
> unmerge 17553 18503
> forcemerge 17838 18503
> stop
> 
>> On 09/19/2014 01:05 AM, Pádraig Brady wrote:
>> unarchive 17553
>> forcemerge 17553 18503
>> stop
>> 
>>> On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
>>> gemfield wrote:
   Hi,
   I am running ls -lsh on kubuntu 14.04, here is the output:
   gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
   4 -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
   gemfield@gemfield-ThinkPad-Edge:~$ ls -lsh
   4.0K -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
   the "4" colored by green means 4 blocks, so why becomes 4.0K blocks
 when add -h option to ls -ls?
>>> 4  * 1K blocks = 4.0K blocks.
>>   ^^ -> bytes
>> 
>> I think the ambiguity is that there is no unit output.
>> With the human output options, bytes are the implicit unit rather than 
>> blocks.
>> 
>> The documentation on the human output options does mention that
>> bytes are being specified rather than blocks:
>> http://www.gnu.org/software/coreutils/manual/coreutils.html#Block-size
>> 
>> Ideally you're right that we should be outputting 4KB
>> or more accurately 4KiB, though due to backward compat concerns
>> we use the less verbose but more ambiguous format.
>> 
>> For more explicit conversions you can run ls through the
>> numfmt utility as described at http://bugs.gnu.org/17553
>> In fact the issues are much the same as with that bug
>> so I'll merge them.
> 
> Actually http://bugs.gnu.org/17838 is essentially the same issue.
> The resolution there was to mention how -h impacts -s in the man page,
> and that improvement was released in coreutils 8.23
> 
> thanks,
> Pádraig.

bug#18503: [bug-report] the output of ls -lsh

[Linda Walsh]

On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
gemfield wrote:  
4  * 1K blocks = 4.0K blocks.

^^ -> bytes
I think the ambiguity is that there is no unit output.
With the human output options, bytes are the implicit unit rather than blocks.


Those darn trees!  Can't see the forest because of...

bug#18503: [bug-report] the output of ls -lsh

[Pádraig Brady]

unmerge 17553 18503
forcemerge 17838 18503
stop

On 09/19/2014 01:05 AM, Pádraig Brady wrote:
> unarchive 17553
> forcemerge 17553 18503
> stop
> 
> On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
>> gemfield wrote:
>>>Hi,
>>>I am running ls -lsh on kubuntu 14.04, here is the output:
>>>gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
>>>4 -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
>>>gemfield@gemfield-ThinkPad-Edge:~$ ls -lsh
>>>4.0K -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
>>>the "4" colored by green means 4 blocks, so why becomes 4.0K blocks
>>>  when add -h option to ls -ls?
>>>   
>> 4  * 1K blocks = 4.0K blocks.
>^^ -> bytes
> 
> I think the ambiguity is that there is no unit output.
> With the human output options, bytes are the implicit unit rather than blocks.
> 
> The documentation on the human output options does mention that
> bytes are being specified rather than blocks:
> http://www.gnu.org/software/coreutils/manual/coreutils.html#Block-size
> 
> Ideally you're right that we should be outputting 4KB
> or more accurately 4KiB, though due to backward compat concerns
> we use the less verbose but more ambiguous format.
> 
> For more explicit conversions you can run ls through the
> numfmt utility as described at http://bugs.gnu.org/17553
> In fact the issues are much the same as with that bug
> so I'll merge them.

Actually http://bugs.gnu.org/17838 is essentially the same issue.
The resolution there was to mention how -h impacts -s in the man page,
and that improvement was released in coreutils 8.23

thanks,
Pádraig.

bug#18503: [bug-report] the output of ls -lsh

[Pádraig Brady]

unarchive 17553
forcemerge 17553 18503
stop

On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
> gemfield wrote:
>>Hi,
>>I am running ls -lsh on kubuntu 14.04, here is the output:
>>gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
>>4 -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
>>gemfield@gemfield-ThinkPad-Edge:~$ ls -lsh
>>4.0K -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
>>the "4" colored by green means 4 blocks, so why becomes 4.0K blocks
>>  when add -h option to ls -ls?
>>   
> 4  * 1K blocks = 4.0K blocks.
^^ -> bytes

I think the ambiguity is that there is no unit output.
With the human output options, bytes are the implicit unit rather than blocks.

The documentation on the human output options does mention that
bytes are being specified rather than blocks:
http://www.gnu.org/software/coreutils/manual/coreutils.html#Block-size

Ideally you're right that we should be outputting 4KB
or more accurately 4KiB, though due to backward compat concerns
we use the less verbose but more ambiguous format.

For more explicit conversions you can run ls through the
numfmt utility as described at http://bugs.gnu.org/17553
In fact the issues are much the same as with that bug
so I'll merge them.

thanks,
Pádraig.

bug#18503: [bug-report] the output of ls -lsh

[Linda A. Walsh]

gemfield wrote:

   Hi,
   I am running ls -lsh on kubuntu 14.04, here is the output:
   gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
   4 -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
   gemfield@gemfield-ThinkPad-Edge:~$ ls -lsh
   4.0K -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
   the "4" colored by green means 4 blocks, so why becomes 4.0K blocks
  
   when add -h option to ls -ls?
  

4  * 1K blocks = 4.0K blocks.

-h has been an option of ls for many years.

blocks in "ls" are 1K in size.

What problem or bug are you reporting?

Seems to be working it ever has(or I'm missing your point).

bug#18503: [bug-report] the output of ls -lsh

[gemfield]

   Hi,
   I am running ls -lsh on kubuntu 14.04, here is the output:
   gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
   4 -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
   gemfield@gemfield-ThinkPad-Edge:~$ ls -lsh
   4.0K -rw-rw-r-- 1 gemfield gemfield9  9 18 23:12 test
   the "4" colored by green means 4 blocks, so why becomes 4.0K blocks
   when add -h option to ls -ls?
   gemfield@gemfield-ThinkPad-Edge:~$ uname -a
   Linux gemfield-ThinkPad-Edge 3.13.0-35-generic #62-Ubuntu SMP Fri Aug
   15 01:58:01 UTC 2014 i686 i686 i686 GNU/Linux
   gemfield@gemfield-ThinkPad-Edge:~$ ls --version
   ls (GNU coreutils) 8.21
   Copyright (C) 2013 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.
   Thanks.
   Gemfield.

bug#18291: Unix Sort Bug Report

[Eric Blake]

On 08/18/2014 09:57 AM, Pádraig Brady wrote:
> On 08/18/2014 09:55 AM, NTENTOS STAVROS wrote:
>>
>> Hello developers,
>>
>> Recently, using the sort utility I run into an omission. While I cannot 
>> disclose the file in question, I will try to explain the issue:
>> On a Windows-created file (line ending: \r\n) I tried to perform a sorting, 
>> which happened to sort the last entry somewhere above. The last line did not 
>> have a line ending of any kind, and sort created a Unix-like ending (\r), 
>> which afterwards creates a parsing problem with the file.
> 
> Well a \n is inserted actually, not \r, but yes that is a problem on windows.
> This demonstrates the behavior:
> 
>   $ printf '2\r\n1' | sort | od -Ax -tx1z -v
>   00 31 0a 32 0d 0a   >1.2..<
> 
> The \n is inserted so as to delimit the reordered item appropriately,
> which is set here:
> 
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/sort.c;h=c2493192;hb=HEAD#l178
> 
> It seems that this should be set to '\r\n' on cygwin builds,
> (wither other adjustments to handle multiple chars).

If the file was opened in text mode, then sort only sees \n line endings
on input (cygwin already shortened \r\n to \n before handing the line to
sort), and on output all \n are automatically converted back to \r\n.
If the file was opened in binary mode, then cygwin CANNOT second guess
what line endings you wanted.  It sounds like your file lives on a
binary mount point, when you want it to live on a text mount point
instead; at which point cygwin should do the right thing (although I
admit I did not actually try this on cygwin, because I seldom use cygwin
text mounts).  But that is probably more a question for cygwin
downstream, not for upstream coreutils (the POSIX requirement is that
text and binary file modes are identical, so any system like cygwin
where there are not is already non-POSIX and starts to get into a
question of whether pushing upstream fixes for a downstream-only problem
is maintainable).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#18291: Unix Sort Bug Report

[Eric Blake]

tag 18291 notabug
thanks

On 08/18/2014 02:55 AM, NTENTOS STAVROS wrote:
> 
> Hello developers,
> 
> Recently, using the sort utility I run into an omission. While I cannot
> disclose the file in question, I will try to explain the issue:
> On a Windows-created file (line ending: \r\n) I tried to perform a
> sorting, which happened to sort the last entry somewhere above. The last
> line did not have a line ending of any kind, and sort created a
> Unix-like ending (\r), which afterwards creates a parsing problem with
> the file.

(Unix line ending is \n, not \r)

Per POSIX, sort(1) is only required to operate on text files with one
exception:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

"The input files shall be text files, except that the sort utility shall
add a  to the end of a file ending with an incomplete last line."

and the POSIX definition of a text file is one that is either empty or
has a trailing newline to begin with:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html

"3.397 Text File"
"A file that contains characters organized into zero or more lines. The
lines do not contain NUL characters and none can exceed {LINE_MAX} bytes
in length, including the  character. Although POSIX.1-2008 does
not distinguish between text files and binary files (see the ISO C
standard), many utilities only produce predictable or meaningful output
when operating on text files. The standard utilities that have such
restrictions always specify "text files" in their STDIN or INPUT FILES
sections."

As such, coreutils is doing what is already required by POSIX, and the
bug is more on you for providing a non-text file without a trailing
newline and expecting sane behavior.  I seriously doubt cygwin can
second-guess your intention to use only windows line endings, and that
you are better off guaranteeing that you have a text file with the
desired line ending already in place than relying on sort's requirement
to add a \n if the file was not a text file merely because it had an
incomplete last line.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#18291: Unix Sort Bug Report

[Pádraig Brady]

On 08/18/2014 09:55 AM, NTENTOS STAVROS wrote:
> 
> Hello developers,
> 
> Recently, using the sort utility I run into an omission. While I cannot 
> disclose the file in question, I will try to explain the issue:
> On a Windows-created file (line ending: \r\n) I tried to perform a sorting, 
> which happened to sort the last entry somewhere above. The last line did not 
> have a line ending of any kind, and sort created a Unix-like ending (\r), 
> which afterwards creates a parsing problem with the file.

Well a \n is inserted actually, not \r, but yes that is a problem on windows.
This demonstrates the behavior:

  $ printf '2\r\n1' | sort | od -Ax -tx1z -v
  00 31 0a 32 0d 0a   >1.2..<

The \n is inserted so as to delimit the reordered item appropriately,
which is set here:

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/sort.c;h=c2493192;hb=HEAD#l178

It seems that this should be set to '\r\n' on cygwin builds,
(wither other adjustments to handle multiple chars).

thanks,
Pádraig.

bug#18291: Unix Sort Bug Report

[NTENTOS STAVROS]

Hello developers,

Recently, using the sort utility I run into an omission. While I  
cannot disclose the file in question, I will try to explain the issue:
On a Windows-created file (line ending: \r\n) I tried to perform a  
sorting, which happened to sort the last entry somewhere above. The  
last line did not have a line ending of any kind, and sort created a  
Unix-like ending (\r), which afterwards creates a parsing problem with  
the file.

--
Ntentos Stavros

bug#13362: GNU bug report logs - #13362 tr does not work with UTF-8 locales

[Ganton]

Dear sirs:

This bugs is causing errors since many years ago (at least twelve (!) 
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139861]), and let's face 
it, if we don't change the point of view it will never get solved. Meanwhile, 
the effects of this bug will keep on damaging the works of Linux users, and our 
reputation.

sed can work with utf-8 correctly. What about asking help from sed developers? 
sed developers could even refactor the tr code so that sed code could be used, 
so at least this bug would not keep on causing errors to Linux users. 
Moreover, sed developers may find a better solution than that one.

Thank you.

bug#16336: bug report tail with hfsplus filesystem

[Pádraig Brady]

On 01/04/2014 06:01 AM, Pádraig Brady wrote:
> On 01/04/2014 03:04 AM, Pieter van Voorst Vader wrote:
>> Hi bug-coreutils,
>> got this bug in tail for a hfsplus filesystem on ubuntu 13.10
>>
>> tail: unrecognized file system type 0x482b for ‘serviio.log’. please 
>> report this to bug-coreutils@gnu.org. reverting to polling
> 
> Cool thanks, we'll add this, probably identified as HFS+
> A little searching also suggests adding 0x4858 for HFSX might be useful also.

Pushed fix at: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=b938b6e2

thanks,
Pádraig.

bug#16561: Bug report for 'head' (and 'wc' et. al.)

[Pádraig Brady]

forcemerge 16561 16329
stop

On 01/26/2014 03:07 PM, LGUC wrote:
>THE INCOMPLETE ATTACMENT! (working on sunday makes not my lucky day.
>Sorry for the inconveniences!.
>Please disregard the previous 2 mails)
>  __
> 
>Caracas, Sunday 26th, 2014
>Ref: Bug report for 'head' (and 'wc' et. al.)
>Dear friends:
>  Please find attached the text file 'head-tst.txt'
> 
>  As you easily can see, the following command fails and do not print
>anything, even if the file has:  6 lines,  49 words and  250 chars:
>  'head -n -0 head-tst.txt'
>  The last line on the file does NOT end with a '\n', and this seems
>to be the base of the problem. If you add the last '\n', 'head' works
>pretty fine.

Right that's an issue, coincidentally recently reported:
http://bugs.gnu.org/16329
We'll include the fix for that soon.

>  So this seems to be a problem with the definition of a 'text line':
>I guess that a line that has around 68 normal chars and 13 spaces, is
>a good candidate to be considered as a line.
>  I found the same problem in several other core utils, being the
>most remarcable 'wc'. If you executes:
>  'wc head-tst.txt'
>  you will get:
>5  49 250 head-tst.txt
>  what is wrong, as the file has six (6) lines instead of five (5).
>The last one line is missing due to the fact that it does not
>include a '\n' at the end.
>  In 1998 I fix 'wc', and I have attached 'wc-fix.c' including only
>the most remarkable aspects, in case it could be of any help.

So wc is different and is defined by POSIX to only count '\n' chars.
So we can't change that really. We might be able to add a --visible-lines
option that would handle this and also unicode line separators etc.
But that would require more debate since it would be a new option.

thanks,
Pádraig.

bug#16336: bug report tail with hfsplus filesystem

[Pádraig Brady]

On 01/04/2014 03:04 AM, Pieter van Voorst Vader wrote:
> Hi bug-coreutils,
> got this bug in tail for a hfsplus filesystem on ubuntu 13.10
> 
> tail: unrecognized file system type 0x482b for ‘serviio.log’. please 
> report this to bug-coreutils@gnu.org. reverting to polling

Cool thanks, we'll add this, probably identified as HFS+
A little searching also suggests adding 0x4858 for HFSX might be useful also.

cheers,
Pádraig.

bug#16336: bug report tail with hfsplus filesystem

[Pieter van Voorst Vader]

Hi bug-coreutils,
got this bug in tail for a hfsplus filesystem on ubuntu 13.10

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


with kind regards,
Pieter

bug#15407: bug report

[Eric Blake]

tag 15407 notabug
thanks

On 09/18/2013 07:07 AM, João Marques wrote:
> Hi good afternoon
> 
> Yesterday i was reading the manual (man date) of the date command and I
> think that the option + and ' isn't refer on it
> 
> so i was trying to make this command on a script:
> 
>  $(date +'%Y-%m-%d '%H:%M:%S')

As written, that's not a valid command, because it has unbalanced
quotes.  ' is not an option character seen by date, but a quoting
metacharacter consumed by the shell.  You may want to read a good manual
on shell quoting; but as a short tutorial, all of the following are
equivalent:

date +%y-%m-%d\ %H:%M:%S
date '+%y-%m-%d %H:%M:%S'
date '+'"%y-%m-%d"' '"%H:%M:%S"

and so on.  To see what the shell actually did with your quote
characters, use echo (and since the output of all three of these
commands is identical, you can understand why I claim that ' is not a
format character recognized by date):

echo date +%y-%m-%d\ %H:%M:%S
echo date '+%y-%m-%d %H:%M:%S'
echo date '+'"%y-%m-%d"' '"%H:%M:%S"

Why some people insist on using '' around most of the FORMAT argument,
but not the leading + portion (that is, why you see +'%y...' instead of
'+%y...' in examples), is beyond me, but it is perfectly valid shell
quoting either way.

> 
> maybe I'm wrong but if not, it was nice to include this information an some
> examples on the  manual
> so that anyone could make it more easily.

Meanwhile, the '+' option IS documented, in both the man and info pages.
 The man page starts out with:

SYNOPSIS
   date [OPTION]... [+FORMAT]
   date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]

See, right there, the leading '+' is what designates a FORMAT argument.
 Failing to use a leading '+' is what tells date to interpret its
argument as MMDDhhmm instead of FORMAT.

Therefore, I'm closing this as not a bug, although you should feel free
to reply with any further questions.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15407: bug report

[João Marques]

Hi good afternoon

Yesterday i was reading the manual (man date) of the date command and I
think that the option + and ' isn't refer on it

so i was trying to make this command on a script:

 $(date +'%Y-%m-%d '%H:%M:%S')

maybe I'm wrong but if not, it was nice to include this information an some
examples on the  manual
so that anyone could make it more easily.

Best regards
João Marques

bug#13947: bug report for core-utils command : OD

[Mark JAEGER]

Hello Eric,

The terms "single-byte character" and "single-byte
printable character" do not sound precise to me.

A byte is just a byte.  It is NOT a character.
I.e., it is an octet, or an 8-bit quantity.

It CAN be interpreted as a character, but only in
the context of a particular ENCODING.

The help text as it stands now IS precise in talking
about ASCII, which IS a particular encoding.

Please don't use the term "single-byte ... character"
without being precise about what encoding it uses.

Regards,

--Mark JAEGER  phone: 312-651-8329
Sustaining Engineering (formerly DDR)
Server Technologies, Oracle   e-mail: mark.jae...@oracle.com


On Fri, 22 Mar 2013, Eric Blake wrote:


Date: Fri, 22 Mar 2013 10:03:47 -0600
From: Eric Blake 
To: Pádraig Brady 
Cc: mark.jae...@oracle.com, Marc Grondin ,
13947-d...@debbugs.gnu.org
Subject: Re: bug#13947: bug report for core-utils command :  OD

On 03/22/2013 09:45 AM, Pádraig Brady wrote:

Hopefully the attached clarifies things.



* src/od.c (usage): Mention any printable character is output,
Not just ASCII.
* doc/coreutils.texi (od invocation): Further clarify that only
single byte characters are output (due to the alignment requirement).
Reported in http://bugs.gnu.org/13947


Yes, this looks good to me.  It could go in as-is, but see my question
below...


---
 doc/coreutils.texi |6 +++---
 src/od.c   |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)




 @table @samp
 @item a
 named character, ignoring high-order bit
 @item c
-ASCII character or backslash escape,
+printable single byte character or backslash escape,


Hmm, we output octal sequences without a backslash; should the info page
be any more verbose that it is one of: a single-byte printable
character, a C backslash escape, or an octal sequence?  Or does that
just clutter things (seeing three octal digits, even without a
backslash, still makes it easy to determine that it can be used as an
escape sequence).


+++ b/src/od.c
@@ -339,7 +339,7 @@ suffixes may be . for octal and b for multiply by 512.\n\
 Traditional format specifications may be intermixed; they accumulate:\n\
   -a   same as -t a,  select named characters, ignoring high-order bit\n\
   -b   same as -t o1, select octal bytes\n\
-  -c   same as -t c,  select ASCII characters or backslash escapes\n\
+  -c   same as -t c,  select printable characters or backslash escapes\n\


For the --help output, terse is good, so I don't see any improvements to
your change here.

--
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org

bug#13947: bug report for core-utils command : OD

[Eric Blake]

On 03/27/2013 12:39 PM, Mark JAEGER wrote:
> Hello Eric,
> 
> The terms "single-byte character" and "single-byte
> printable character" do not sound precise to me.

They are precise - they are characters in the encoding determined by the
current setting of LC_CTYPE.

> 
> A byte is just a byte.  It is NOT a character.
> I.e., it is an octet, or an 8-bit quantity.
> 
> It CAN be interpreted as a character, but only in
> the context of a particular ENCODING.

Yes, but the ENCODING is always known, thanks to the rules on LC_* and
locale handling.

> 
> The help text as it stands now IS precise in talking
> about ASCII, which IS a particular encoding.
> 
> Please don't use the term "single-byte ... character"
> without being precise about what encoding it uses.

The encoding is whatever encoding you asked for.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#13947: bug report for core-utils command : OD

[Pádraig Brady]

On 03/22/2013 04:03 PM, Eric Blake wrote:
> On 03/22/2013 09:45 AM, Pádraig Brady wrote:
>>  @table @samp
>>  @item a
>>  named character, ignoring high-order bit
>>  @item c
>> -ASCII character or backslash escape,
>> +printable single byte character or backslash escape,
> 
> Hmm, we output octal sequences without a backslash; should the info page
> be any more verbose that it is one of: a single-byte printable
> character, a C backslash escape, or an octal sequence?  Or does that
> just clutter things (seeing three octal digits, even without a
> backslash, still makes it easy to determine that it can be used as an
> escape sequence).

Good point.
I'll make that clarification in the same commit as it at least confirms the
behavior is intended. POSIX is explicit about the three possibilities.

thanks,
Pádraig.

bug#13947: bug report for core-utils command : OD

[Eric Blake]

On 03/22/2013 09:45 AM, Pádraig Brady wrote:
> Hopefully the attached clarifies things.

> * src/od.c (usage): Mention any printable character is output,
> Not just ASCII.
> * doc/coreutils.texi (od invocation): Further clarify that only
> single byte characters are output (due to the alignment requirement).
> Reported in http://bugs.gnu.org/13947

Yes, this looks good to me.  It could go in as-is, but see my question
below...

> ---
>  doc/coreutils.texi |6 +++---
>  src/od.c   |4 ++--
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 

>  @table @samp
>  @item a
>  named character, ignoring high-order bit
>  @item c
> -ASCII character or backslash escape,
> +printable single byte character or backslash escape,

Hmm, we output octal sequences without a backslash; should the info page
be any more verbose that it is one of: a single-byte printable
character, a C backslash escape, or an octal sequence?  Or does that
just clutter things (seeing three octal digits, even without a
backslash, still makes it easy to determine that it can be used as an
escape sequence).

> +++ b/src/od.c
> @@ -339,7 +339,7 @@ suffixes may be . for octal and b for multiply by 512.\n\
>  Traditional format specifications may be intermixed; they accumulate:\n\
>-a   same as -t a,  select named characters, ignoring high-order bit\n\
>-b   same as -t o1, select octal bytes\n\
> -  -c   same as -t c,  select ASCII characters or backslash escapes\n\
> +  -c   same as -t c,  select printable characters or backslash escapes\n\

For the --help output, terse is good, so I don't see any improvements to
your change here.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#13947: bug report for core-utils command : OD

[Pádraig Brady]

On 03/13/2013 09:53 PM, Pádraig Brady wrote:
> On 03/13/2013 09:34 PM, Eric Blake wrote:
>> In reality, that should state something like:
> 
>>  Output as characters in the current locale, using octal sequences
>> or backslash escapes for all non-graphic bytes.
> 
> Note we output spaces, so I'd s/non-graphic/non-printable/.
> 
> Also multi byte is always going to be problematic displaying
> in a grid like this, so we'll probably continue to do as
> we do now for the utf8 example above and output octal and dots.
> So therefore s/characters/single byte characters/.

Hopefully the attached clarifies things.

thanks,
Pádraig.
>From 1f9a6a48bbc05599092cb5da2429ab3ccfe87631 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Fri, 22 Mar 2013 15:33:57 +
Subject: [PATCH] doc: clarify the printable characters output by od

* src/od.c (usage): Mention any printable character is output,
Not just ASCII.
* doc/coreutils.texi (od invocation): Further clarify that only
single byte characters are output (due to the alignment requirement).
Reported in http://bugs.gnu.org/13947
---
 doc/coreutils.texi |6 +++---
 src/od.c   |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 8f1df45..d2f3b21 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -1908,14 +1908,14 @@ of each output line using each of the data types that you specified,
 in the order that you specified.
 
 Adding a trailing ``z'' to any type specification appends a display
-of the ASCII character representation of the printable characters
+of the single byte character representation of the printable characters
 to the output line generated by the type specification.
 
 @table @samp
 @item a
 named character, ignoring high-order bit
 @item c
-ASCII character or backslash escape,
+printable single byte character or backslash escape,
 @item d
 signed decimal
 @item f
@@ -2003,7 +2003,7 @@ Output as octal bytes.  Equivalent to @samp{-t o1}.
 
 @item -c
 @opindex -c
-Output as ASCII characters or backslash escapes.  Equivalent to
+Output as printable single byte characters or backslash escapes.  Equivalent to
 @samp{-t c}.
 
 @item -d
diff --git a/src/od.c b/src/od.c
index e7d881b..e8cab46 100644
--- a/src/od.c
+++ b/src/od.c
@@ -339,7 +339,7 @@ suffixes may be . for octal and b for multiply by 512.\n\
 Traditional format specifications may be intermixed; they accumulate:\n\
   -a   same as -t a,  select named characters, ignoring high-order bit\n\
   -b   same as -t o1, select octal bytes\n\
-  -c   same as -t c,  select ASCII characters or backslash escapes\n\
+  -c   same as -t c,  select printable characters or backslash escapes\n\
   -d   same as -t u2, select unsigned decimal 2-byte units\n\
 "), stdout);
   fputs (_("\
@@ -355,7 +355,7 @@ Traditional format specifications may be intermixed; they accumulate:\n\
 \n\
 TYPE is made up of one or more of these specifications:\n\
   a  named character, ignoring high-order bit\n\
-  c  ASCII character or backslash escape\n\
+  c  printable character or backslash escape\n\
 "), stdout);
   fputs (_("\
   d[SIZE]signed decimal, SIZE bytes per integer\n\
-- 
1.7.7.6

bug#13947: bug report for core-utils command : OD

[Pádraig Brady]

On 03/13/2013 09:34 PM, Eric Blake wrote:
> On 03/13/2013 02:16 PM, Marc Grondin wrote:
>> Good Afternoon, 
> 
> Hello, and thanks for the report.
> 
>>
>> My client was attempting to run the command : od -c on this xml file (sample 
>> only) 
>> --
>> 
>> 
>>丸
> 
> Here, you are representing a character in UTF-8
> 
>> He was getting this output : 
>> --
>> 000   <   ?   x   m   l   v   e   r   s   i   o   n   =
>> 020   '   1   .   0   '   e   n   c   o   d   i   n   g   =
>> 040   '   U   T   F   -   8   '   ?   >  \n   <   t   o   p   >
>> 060  \n   <   x   >   �   �   �   <   /   x   >  \n
> 
> and here, you were running od in a different character set:
> 
>> This all based on the LANG env.  He was using : 
>> LANG=en_US.iso88591, instead of
>> LANG=en_US.UTF-8 
> 
> In ISO-88591, every byte is a character, and those particular bytes
> happen to be printable, so od was faithfully replaying the character as
> printable, only to then be shown by your UTF-8 terminal as an invalid
> UTF-8 sequence.  Mismatching character sets between your program and
> your terminal is always a recipe for confusion.
> 
> However, you HAVE identified a bug, in our documentation.
> 
>>
>> --
>>
>> Question : 
>> Since the output is based on the ASCII character set, should it not, in both 
>> cases give a numerical output (as it did in scenario #2) 
>> for a symbol outside the ascii/extended-ascii character set ? 
> 
> Our documentation is lying.  Here's what POSIX says about od -c:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html
> "Interpret bytes as characters specified by the current setting of the
> LC_CTYPE category. Certain non-graphic characters appear as C escapes:
> "NUL=\0" , "BS=\b" , "FF=\f" , "NL=\n" , "CR=\r" , "HT=\t" ; others
> appear as 3-digit octal numbers."
> 
> Nothing in there restricts the output to ASCII only.  The bytes that are
> showing up as � are graphic characters in your current choice of
> LC_CTYPE, so there is no escaping performed (since escaping is permitted
> only on non-graphic characters).  If your terminal was using the same
> character set as you ran od under, you would see proper graphical
> characters in the ISO-88591 set (but then again, you wouldn't see the
> nice 丸 character that the UTF-8 was representing).
> 
> Coreutils is properly obeying the locale, what is wrong is the info
> documentation which stated:
> 
> `-c'
>  Output as ASCII characters or backslash escapes.

I agree. Thanks for the detailed description.

> In reality, that should state something like:

>  Output as characters in the current locale, using octal sequences
> or backslash escapes for all non-graphic bytes.

Note we output spaces, so I'd s/non-graphic/non-printable/.

Also multi byte is always going to be problematic displaying
in a grid like this, so we'll probably continue to do as
we do now for the utf8 example above and output octal and dots.
So therefore s/characters/single byte characters/.

> 
> Meanwhile, if you want to guarantee ASCII-only output from od, you have
> to use a different format, such as -b or -tx1, or use LC_ALL=C on a
> system where the C locale does not treat non-ascii bytes as graphical
> characters (most glibc systems, including the one you are using, fit
> this bill).
> 

cheers,
Pádraig.

bug#13947: bug report for core-utils command : OD

[Eric Blake]

On 03/13/2013 02:16 PM, Marc Grondin wrote:
> Good Afternoon, 

Hello, and thanks for the report.

> 
> My client was attempting to run the command : od -c on this xml file (sample 
> only) 
> --
> 
> 
>丸

Here, you are representing a character in UTF-8

> He was getting this output : 
> --
> 000   <   ?   x   m   l   v   e   r   s   i   o   n   =
> 020   '   1   .   0   '   e   n   c   o   d   i   n   g   =
> 040   '   U   T   F   -   8   '   ?   >  \n   <   t   o   p   >
> 060  \n   <   x   >   �   �   �   <   /   x   >  \n

and here, you were running od in a different character set:

> This all based on the LANG env.  He was using : 
> LANG=en_US.iso88591, instead of
> LANG=en_US.UTF-8 

In ISO-88591, every byte is a character, and those particular bytes
happen to be printable, so od was faithfully replaying the character as
printable, only to then be shown by your UTF-8 terminal as an invalid
UTF-8 sequence.  Mismatching character sets between your program and
your terminal is always a recipe for confusion.

However, you HAVE identified a bug, in our documentation.

> 
> --
> 
> Question : 
> Since the output is based on the ASCII character set, should it not, in both 
> cases give a numerical output (as it did in scenario #2) 
> for a symbol outside the ascii/extended-ascii character set ? 

Our documentation is lying.  Here's what POSIX says about od -c:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html
"Interpret bytes as characters specified by the current setting of the
LC_CTYPE category. Certain non-graphic characters appear as C escapes:
"NUL=\0" , "BS=\b" , "FF=\f" , "NL=\n" , "CR=\r" , "HT=\t" ; others
appear as 3-digit octal numbers."

Nothing in there restricts the output to ASCII only.  The bytes that are
showing up as � are graphic characters in your current choice of
LC_CTYPE, so there is no escaping performed (since escaping is permitted
only on non-graphic characters).  If your terminal was using the same
character set as you ran od under, you would see proper graphical
characters in the ISO-88591 set (but then again, you wouldn't see the
nice 丸 character that the UTF-8 was representing).

Coreutils is properly obeying the locale, what is wrong is the info
documentation which stated:

`-c'
 Output as ASCII characters or backslash escapes.

In reality, that should state something like:
 Output as characters in the current locale, using octal sequences
or backslash escapes for all non-graphic bytes.

Meanwhile, if you want to guarantee ASCII-only output from od, you have
to use a different format, such as -b or -tx1, or use LC_ALL=C on a
system where the C locale does not treat non-ascii bytes as graphical
characters (most glibc systems, including the one you are using, fit
this bill).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#13947: bug report for core-utils command : OD

[Marc Grondin]

Good Afternoon, 

My client was attempting to run the command : od -c on this xml file (sample 
only) 
--


   丸
   丸
   𠄌
   ?
   ?
   ?丸
   ??丸

--

note : this system is a : 2.6.18-164.0.0.0.1.el5xen #1 SMP Thu Sep 3 00:34:43 
EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

He was getting this output : 
--
000   <   ?   x   m   l   v   e   r   s   i   o   n   =
020   '   1   .   0   '   e   n   c   o   d   i   n   g   =
040   '   U   T   F   -   8   '   ?   >  \n   <   t   o   p   >
060  \n   <   x   >   �   �   �   <   /   x   >  \n
100   <   y   >   �   �   � 201   <   /   y   >  \n
120   <   z   >   �   � 204 214   <   /   z   >  \n
140   <   x   >   ?   <   /   x   >  \n   <   x   >   ?
160   <   /   x   >  \n   <   x   >   ?   �   �   � 201
200   <   /   x   >  \n   <   x   >   ?   ?   �   �   �
220 201   <   /   x   >  \n   <   /   t   o   p   >  \n
--

Instead of this : 
--
00   <   ?   x   m   l   v   e   r   s   i   o   n   =
020   '   1   .   0   '   e   n   c   o   d   i   n   g   =
040   '   U   T   F   -   8   '   ?   >  \n   <   t   o   p   >
060  \n   <   x   > 344 270 270   <   /   x   >  \n
100   <   y   > 360 257 240 201   <   /   y   >  \n
120   <   z   > 360 240 204 214   <   /   z   >  \n
140   <   x   >   ?   <   /   x   >  \n   <   x   >   ?
160   <   /   x   >  \n   <   x   >   ? 360 257 240 201
200   <   /   x   >  \n   <   x   >   ?   ? 360 257 240
220 201   <   /   x   >  \n   <   /   t   o   p   >  \n
235
--

This all based on the LANG env.  He was using : 
LANG=en_US.iso88591, instead of
LANG=en_US.UTF-8 

--

Question : 
Since the output is based on the ASCII character set, should it not, in both 
cases give a numerical output (as it did in scenario #2) 
for a symbol outside the ascii/extended-ascii character set ? 
--


Regards, 

Marc Grondin, 

__
Oracle - Quebec city, Qc.
Senior System Administrator, PDIT
-
400-330 St-Vallier, G1K 9C5
418.524.5665 # 1256
=

bug#12659: the join command bug report!

[Michael]

" Important: FILE1 and FILE2 must be sorted on the join fields."

There is only words above in the manual. it should mention the sort method 
at least. I strongly suggest improve the join maunal in the latter 
distribution.


Thanks

Michael


--
From: "Paul Eggert" 
Sent: Wednesday, October 17, 2012 11:14 PM
To: "Michael" 
Cc: <12...@debbugs.gnu.org>
Subject: Re: bug#12659: the join command bug report!


On 10/17/2012 12:19 AM, Michael wrote:

# sort -n file1 > file3
# sort -n file2 > file4

# join file3 file4


That won't work.  You have to join with the same
sorting order that you sorted with.  This is discussed
in the manual.

bug#12659: the join command bug report!

[Bob Proulx]

Paul Eggert wrote:
> On 10/17/2012 12:19 AM, Michael wrote:
> > # sort -n file1 > file3
> > # sort -n file2 > file4
> > 
> > # join file3 file4
> 
> That won't work.  You have to join with the same
> sorting order that you sorted with.  This is discussed
> in the manual.

Since this seems to have been resolved satisfactorily I have closed
the bug report.  If you have any further information please feel free
to respond as I have done here and it will be delivered to all of the
interested parties.

Bob

bug#12659: the join command bug report!

[Paul Eggert]

On 10/17/2012 12:19 AM, Michael wrote:
> # sort -n file1 > file3
> # sort -n file2 > file4
> 
> # join file3 file4

That won't work.  You have to join with the same
sorting order that you sorted with.  This is discussed
in the manual.

bug#12659: the join command bug report!

[Michael]

en_US.UTF-8

# sort -n file1 > file3
# sort -n file2 > file4

# join file3 file4 | wc -l
19
# sort file3 file4 | uniq -d | wc -l
4698
#

There are only numbers in my both joined files, I have realized that join 
does not support numeric sort method for the time being. if sort without 
option '-n', the result after joining was correct.


Michael

--
From: "Paul Eggert" 
Sent: Wednesday, October 17, 2012 12:10 AM
To: "Michael" 
Cc: <12...@debbugs.gnu.org>
Subject: Re: bug#12659: the join command bug report!


Sounds like a locale problem.  What does the "locale"
command say?  How exactly are you invoking 'sort' and
'join'?  What do the input and output lines look like?

bug#12659: the join command bug report!

[Paul Eggert]

Sounds like a locale problem.  What does the "locale"
command say?  How exactly are you invoking 'sort' and
'join'?  What do the input and output lines look like?