bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x

[Philipp Thomas]

* Pádraig Brady (p...@draigbrady.com) [20140919 02:59]:

> http://valgrind.org/docs/manual/dist.readme-missing.html
> 
> The patch in this case seems simple?
> https://bugs.kde.org/show_bug.cgi?id=331337

Must be something else as the valgrind 3.10.0 we use has this fixed. So the
reason must be something else. For the time being I've simply removed
valgrind from the call.

Philipp

bug#18506: stty dsusp undef fails.

[Edward Huff]

$ stty dsusp undef
stty: invalid argument ‘dsusp’
Try 'stty --help' for more information.
$ stty --help | grep dsusp
 * dsusp CHARCHAR will send a terminal stop signal once input flushed
$ stty --version
stty (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 David MacKenzie.
$

bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x

[Bernhard Voelker]

On 09/19/2014 02:59 AM, Pádraig Brady wrote:

FAIL: tests/misc/shuf-reservoir
===



+ valgrind --leak-check=summary --error-exitcode=1 shuf -n 1 -o out_1_1
==10209== Memcheck, a memory error detector
==10209== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10209== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==10209== Command: shuf -n 1 -o out_1_1
==10209==
+ seq 1
--10209-- WARNING: unhandled syscall: 326
--10209-- You may be able to write your own handler.
--10209-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--10209-- Nevertheless we consider this a bug.  Please report
--10209-- it at http://valgrind.org/support/bug_reports.html.
1
==10209==
==10209== HEAP SUMMARY:
==10209== in use at exit: 37,112 bytes in 5 blocks
==10209==   total heap usage: 8 allocs, 3 frees, 37,188 bytes allocated
==10209==
==10209== LEAK SUMMARY:
==10209==definitely lost: 32,832 bytes in 3 blocks
==10209==indirectly lost: 4,280 bytes in 2 blocks
==10209==  possibly lost: 0 bytes in 0 blocks
==10209==still reachable: 0 bytes in 0 blocks
==10209== suppressed: 0 bytes in 0 blocks
==10209== Rerun with --leak-check=full to see details of leaked memory
==10209==
==10209== For counts of detected and suppressed errors, rerun with: -v
==10209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+ EXPECTED_LINES=1
+ test 1 -lt 1
++ grep '^[0-9][0-9]*$' out_1_1
++ sort -un
++ wc -l
+ GOOD_LINES=0
++ wc -l
+ LINES=0
+ test 1 -eq 0
+ return 1
+ fail=1
+ echo 'shuf-reservoir-sampling failed with IN_N=1 OUT_N=1'
shuf-reservoir-sampling failed with IN_N=1 OUT_N=1


It seems to be a limitation of the valgrind implementation on your system,
which is causing valgrind to bail out without shuf outputting anything?
I could put an explicit check for that and skip in the test,
however it would be best to avoid that by fixing valgrind instead.

http://valgrind.org/docs/manual/dist.readme


IMO there's something weird additionally going on here:

If valgrind doesn't work, then it should exit non-Zero.
As it doesn't, I assume it runs shuf(1). As shuf(1) creates
the output file itself via the -o option, this is the proof
the it has really run (and wc(1) would complain otherwise).

BUT: all invocations in the log output lead to LINES=0!
That would mean that 'shuf -n' really is not working on s390x,
it always produces an empty file.

@Philipp: can you confirm please? I don't have access to
such a s390x machine ...

Have a nice day,
Berny

bug#18506: stty dsusp undef fails.

[Pádraig Brady]

tag 18506 notabug
close 18506
stop

On 09/19/2014 03:09 AM, Edward Huff wrote:
> $ stty dsusp undef
> stty: invalid argument ‘dsusp’
> Try 'stty --help' for more information.
> $ stty --help | grep dsusp
>  * dsusp CHARCHAR will send a terminal stop signal once input flushed
> $ stty --version
> stty (GNU coreutils) 8.21

The dsusp entry is tagged with "*" to indicate it's not a POSIX setting,
and just above the --help says: "The underlying system defines which settings 
are available."
So it's just the case that this setting is not available on your system,
which is the case for Linux for example. Ideally the listed options would
be dynamic and not list this as an option for you, but this would complicate
the man page generation.

thanks,
Pádraig.

bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x

[Philipp Thomas]

* Bernhard Voelker (m...@bernhard-voelker.de) [20140919 10:36]:

> @Philipp: can you confirm please? I don't have access to
> such a s390x machine ...

I could check it, but the test succeeds if I remove the valgrind invocation.

Philipp

bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x

[Philipp Thomas]

* Bernhard Voelker (m...@bernhard-voelker.de) [20140919 10:36]:

> @Philipp: can you confirm please? I don't have access to
> such a s390x machine ...

Nope,

running ls -l | shuf -n 5

succeeds as it should,

Philipp

bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x

[Bernhard Voelker]

On 09/19/2014 12:46 PM, Philipp Thomas wrote:

* Bernhard Voelker (m...@bernhard-voelker.de) [20140919 10:36]:

@Philipp: can you confirm please? I don't have access to
such a s390x machine ...


Nope,

running ls -l | shuf -n 5

succeeds as it should,


Huh? That means that in that test
* valgrind runs shuf
* shuf creates the output file
* but shuf does not write anything to that output file.

And that in turn means that valgrind is modifying the
shuf(1) run so that it only halfway works.
Am I right so far?

Have a nice day,
Berny

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#18506: stty dsusp undef fails.

[Pádraig Brady]

On 09/19/2014 10:05 AM, Pádraig Brady wrote:
> tag 18506 notabug
> close 18506
> stop
> 
> On 09/19/2014 03:09 AM, Edward Huff wrote:
>> $ stty dsusp undef
>> stty: invalid argument ‘dsusp’
>> Try 'stty --help' for more information.
>> $ stty --help | grep dsusp
>>  * dsusp CHARCHAR will send a terminal stop signal once input flushed
>> $ stty --version
>> stty (GNU coreutils) 8.21
> 
> The dsusp entry is tagged with "*" to indicate it's not a POSIX setting,
> and just above the --help says: "The underlying system defines which settings 
> are available."
> So it's just the case that this setting is not available on your system,
> which is the case for Linux for example. Ideally the listed options would
> be dynamic and not list this as an option for you, but this would complicate
> the man page generation.

However man pages are generated at build time now,
so we might consider eliding non applicable items?

The caveat to that is that man pages generated and
then copied on the web somewhere would be less general.

I'm leaning towards that actually as currently we
don't distinguish "invalid argument" from "not supported" errors.

Proposed patch attached.

thanks,
Pádraig.
>From be1e555db9cfd7e82a0a26e1a612a65ebe93d789 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Fri, 19 Sep 2014 16:15:04 +0100
Subject: [PATCH] stty: only list supported options in --help and man pages

* src/stty.c (usage): Exclude unsupported options from --help,
which only impacts the "dsusp" option on GNU/Linux.
Fixes http://bugs.gnu.org/18506
---
 src/stty.c |  177 ++--
 1 files changed, 173 insertions(+), 4 deletions(-)

diff --git a/src/stty.c b/src/stty.c
index 9e4c530..e306672 100644
--- a/src/stty.c
+++ b/src/stty.c
@@ -539,45 +539,84 @@ settings.  The underlying system defines which settings are available.\n\
 "), stdout);
   fputs (_("\
 \n\
-Special characters:\n\
+Special characters:\n"), stdout);
+#ifdef VDSUSP
+  fputs (_("\
  * dsusp CHARCHAR will send a terminal stop signal once input flushed\n\
+"), stdout);
+#endif
+  fputs (_("\
eof CHAR  CHAR will send an end of file (terminate the input)\n\
eol CHAR  CHAR will end the line\n\
 "), stdout);
+#ifdef VEOL2
   fputs (_("\
  * eol2 CHAR alternate CHAR for ending the line\n\
+"), stdout);
+#endif
+  fputs (_("\
erase CHARCHAR will erase the last character typed\n\
intr CHAR CHAR will send an interrupt signal\n\
kill CHAR CHAR will erase the current line\n\
 "), stdout);
+#ifdef VLNEXT
   fputs (_("\
  * lnext CHARCHAR will enter the next character quoted\n\
+"), stdout);
+#endif
+  fputs (_("\
quit CHAR CHAR will send a quit signal\n\
+"), stdout);
+# ifdef CREPRINT /* HPUX 10.20 needs this */
+  fputs (_("\
  * rprnt CHARCHAR will redraw the current line\n\
-   start CHARCHAR will restart the output after stopping it\n\
 "), stdout);
+#endif
   fputs (_("\
+   start CHARCHAR will restart the output after stopping it\n\
stop CHAR CHAR will stop the output\n\
susp CHAR CHAR will send a terminal stop signal\n\
+"), stdout);
+#ifdef VSWTCH
+  fputs (_("\
  * swtch CHARCHAR will switch to a different shell layer\n\
+"), stdout);
+#endif
+#ifdef VWERASE
+  fputs (_("\
  * werase CHAR   CHAR will erase the last word typed\n\
 "), stdout);
+#endif
   fputs (_("\
 \n\
 Special settings:\n\
N set the input and output speeds to N bauds\n\
+"), stdout);
+#ifdef TIOCGWINSZ
+  fputs (_("\
  * cols Ntell the kernel that the terminal has N columns\n\
  * columns N same as cols N\n\
 "), stdout);
+#endif
   fputs (_("\
ispeed N  set the input speed to N\n\
+"), stdout);
+#ifdef HAVE_C_LINE
+  fputs (_("\
  * line Nuse line discipline N\n\
+"), stdout);
+#endif
+  fputs (_("\
min N with -icanon, set N characters minimum for a completed read\n\
ospeed N  set the output speed to N\n\
 "), stdout);
+#ifdef TIOCGWINSZ
   fputs (_("\
  * rows Ntell the kernel that the terminal has N rows\n\
  * size  print the number of rows and columns according to the kernel\n\
+"), stdout);
+#endif
+  fputs (_("\
speed print the terminal speed\n\
time Nwith -icanon, set read timeout of N tenths of a second\n\
 "), stdout);
@@ -586,8 +625,18 @@ Special settings:\n\
 Control settings:\n\
[-]clocal disable modem control signals\n\
[-]cread  allow input to be received\n\
+"), stdout);
+#ifdef CRTSCTS
+  fputs (_("\
  * [-]crtsctsenable RTS/CTS handshaking\n\
+"), stdout);
+#endif
+#ifdef CDTRDSR
+  fputs (_("\
  * [-]cdtrdsrenable DTR/DSR handshaking\n\
+"), stdout);
+#endif
+  fputs (_("\
csN   set character size to N bits, N in [5..8]\n\
 "), stdout);
   fputs (_("\
@@ -596,8 +645,12 @@ Control settings:\n\
[-

bug#18436: Error building 8.23 with builddir != srcdir and --disable-dependency-tracking

[Pádraig Brady]

forcemerge 18055 18436
stop

On 09/09/2014 08:57 PM, Daniel Richard G. wrote:
> I normally build with --disable-dependency-tracking to speed up builds,
> and also build out-of-tree, and got this with the latest coreutils:
> 
> $ cd /foo/bar/coreutils-8.23
> $ mkdir _build
> $ cd _build
> $ ../configure --disable-dependency-tracking
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> [...]
> $ make
> [...]
>   GEN  lib/unistr.h
>   GEN  lib/unitypes.h
>   GEN  lib/uniwidth.h
>   GEN  lib/wchar.h
>   GEN  lib/wctype.h
>   GEN  src/coreutils.h
> /bin/sh: src/coreutils.ht: No such file or directory
> gmake: *** [src/coreutils.h] Error 1

This is essentially the same issue as http://bugs.gnu.org/18055
I'm guessing tha dependency tracking is disabled there too for the distro
as it's not needed for once off builds, and then doing parallel make
builds compounds the issue.

We could fix it for GNU and solaris make but break on BSD
(since it doesn't support included makefiles) like:

  diff --git a/man/local.mk b/man/local.mk
  index f2d1357..0464cf1 100644
  --- a/man/local.mk
  +++ b/man/local.mk
  @@ -78,7 +78,7 @@ man/dynamic-deps.mk: Makefile
  && mv $@-t $@

   # Include the generated man dependencies.
  -@AMDEP_TRUE@@am__include@ man/dynamic-deps.mk
  +@am__include@ man/dynamic-deps.mk


We could work nicely for all once off builds like,
but require rebuilding all man pages for any change for devs with:

  diff --git a/man/local.mk b/man/local.mk
  index f2d1357..888ff10 100644
  --- a/man/local.mk
  +++ b/man/local.mk
  @@ -41,7 +41,7 @@ distclean-local:
  test x$(srcdir) = x$(builddir) || rm -f $(ALL_MANS)

   # Dependencies common to all man pages.  Updated below.
  -mandeps =
  +mandeps = $(bin_PROGRAMS)

   # Depend on this to get version number changes.
   mandeps += .version
  @@ -77,9 +77,6 @@ man/dynamic-deps.mk: Makefile
  done > $@-t \
  && mv $@-t $@

  -# Include the generated man dependencies.
  -@AMDEP_TRUE@@am__include@ man/dynamic-deps.mk


It would be nice to rely on GNU make for dynamic rules or
order-only prerequisites which would nicely handle things.
However it's best to stick with portable make for now
due to the low level nature of coreutils which might be
required to build gnu make etc. for example.

Instead the attached patch simplifies things by avoiding
the dynamically generated makefile entirely.

There are still a few foibles with parallel make syntax-check
in --enable-single-binary mode, but I've a handle on that edge case
which we can fix up later.

thanks,
Pádraig.
>From 1e235119d175a78ed54a910d7babe2165fff9483 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Fri, 19 Sep 2014 16:49:26 +0100
Subject: [PATCH] build: fix dependency issues with man page generation

* .gitignore: Remove reference to no longer generated make file.
* configure.ac: Don't bother generating placeholder make file.
* man/local.mk: Hardcode the man page deps list for normal builds
to be compatible with all make implementations and configure options.
Note in SINGLE_BINARY mode, all man pages will be generated on
any change to the coreutils binary, but development will generally
not be done in this mode, so this shouldn't be an issue.

Fixes http://bugs.gnu.org/18055
---
 .gitignore   |1 -
 configure.ac |9 
 man/local.mk |  139 ++---
 3 files changed, 112 insertions(+), 37 deletions(-)

diff --git a/.gitignore b/.gitignore
index 02a61e8..885d309 100644
--- a/.gitignore
+++ b/.gitignore
@@ -134,7 +134,6 @@
 /m4/xsize.m4
 /maint.mk
 /man/*.1
-/man/dynamic-deps.mk
 /po/*.gmo
 /po/*.po
 /po/.gitignore
diff --git a/configure.ac b/configure.ac
index f45b06e..0744964 100644
--- a/configure.ac
+++ b/configure.ac
@@ -589,15 +589,6 @@ AM_GNU_GETTEXT_VERSION([0.18.1])
 # For a test of uniq: it uses the $LOCALE_FR envvar.
 gt_LOCALE_FR
 
-# If doing dynamic dependency checking, create man/dynamic-deps.mk so
-# that 'make' doesn't complain about its being absent.  Use an old
-# time stamp, so that 'make' thinks it is older than 'Makefile'.
-# Use time stamp 1, since some 'make' implementations treat 0 specially.
-# Use 'touch -t', since older 'touch' implementations don't grok -d.
-AC_CONFIG_COMMANDS([man/dynamic-deps.mk],
-  [test -n "$AMDEP_TRUE" ||
-   TZ=UTC0 touch -t 19700101.01 man/dynamic-deps.mk])
-
 AC_CONFIG_FILES(
   Makefile
   po/Makefile.in
diff --git a/man/local.mk b/man/local.mk
index f2d1357..aadb540 100644
--- a/man/local.mk
+++ b/man/local.mk
@@ -52,33 +52,118 @@ mandeps += $(top_srcdir)/src/system.h
 
 $(ALL_MANS): $(mandeps)
 
-# Most prog.1 man pages depend on src/$prog, except when they are part of a
-# single binary, in which case they depend on src/coreutils. The exceptions
-# are handle

bug#18506: stty dsusp undef fails.

[Bernhard Voelker]

On 09/19/2014 05:19 PM, Pádraig Brady wrote:
> From be1e555db9cfd7e82a0a26e1a612a65ebe93d789 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
> Date: Fri, 19 Sep 2014 16:15:04 +0100
> Subject: [PATCH] stty: only list supported options in --help and man pages
> 
> * src/stty.c (usage): Exclude unsupported options from --help,
> which only impacts the "dsusp" option on GNU/Linux.

that one, too:

-* [\-]cdtrdsr
-enable DTR/DSR handshaking
-.TP


A slightly different idea: as this can only happen for non-POSIX
options, we could change the '*' symbol to e.g. 'S' ("supported
non-POSIX option) and 'U' (unsupported non-POSIX option).
WDYT?

The cleanest solution probably would be to distinguish between
distinguish "invalid argument" from "not supported" errors, as you
aleady said. I'm not sure if it's worthwhile.

Otherwise: +1

Thanks & have a nice day,
Berny

bug#18436: Error building 8.23 with builddir != srcdir and --disable-dependency-tracking

[Bernhard Voelker]

On 09/19/2014 06:36 PM, Pádraig Brady wrote:
> Subject: [PATCH] build: fix dependency issues with man page generation
> 
> * .gitignore: Remove reference to no longer generated make file.
> * configure.ac: Don't bother generating placeholder make file.
> * man/local.mk: Hardcode the man page deps list for normal builds
> to be compatible with all make implementations and configure options.
> Note in SINGLE_BINARY mode, all man pages will be generated on
> any change to the coreutils binary, but development will generally
> not be done in this mode, so this shouldn't be an issue.

It is:

  $ make clean
  $ make
  $ make syntax-check -j
  ...
  help2man: can't get `--help' info from man/coreutils.td/coreutils
  Try `--no-discard-stderr' if option outputs to stderr
  prohibit_inttostr_without_use
  prohibit_jm_in_m4
  make: *** [man/coreutils.1] Error 127
  make: *** Waiting for unfinished jobs

This only goes away without -j here.

Otherwise +1.

Thanks & have a nice day,
Berny

bug#18506: stty dsusp undef fails.

[Bernhard Voelker]

On 09/19/2014 08:45 PM, Bernhard Voelker wrote:
> On 09/19/2014 05:19 PM, Pádraig Brady wrote:
>> From be1e555db9cfd7e82a0a26e1a612a65ebe93d789 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
>> Date: Fri, 19 Sep 2014 16:15:04 +0100
>> Subject: [PATCH] stty: only list supported options in --help and man pages

oops, the syntax-check doesn't pass:

cppi: src/stty.c: line 570: not properly indented
maint.mk: incorrect preprocessor indentation
make: *** [sc_preprocessor_indentation] Error 1

sed -i -e '570 s/^# ifdef/#ifdef/' src/stty.c

Have a nice day,
Berny

bug#18436: Error building 8.23 with builddir != srcdir and --disable-dependency-tracking

[Pádraig Brady]

On 09/19/2014 08:19 PM, Bernhard Voelker wrote:
> On 09/19/2014 06:36 PM, Pádraig Brady wrote:
>> Subject: [PATCH] build: fix dependency issues with man page generation
>>
>> * .gitignore: Remove reference to no longer generated make file.
>> * configure.ac: Don't bother generating placeholder make file.
>> * man/local.mk: Hardcode the man page deps list for normal builds
>> to be compatible with all make implementations and configure options.
>> Note in SINGLE_BINARY mode, all man pages will be generated on
>> any change to the coreutils binary, but development will generally
>> not be done in this mode, so this shouldn't be an issue.
> 
> It is:
> 
>   $ make clean
>   $ make
>   $ make syntax-check -j
>   ...
>   help2man: can't get `--help' info from man/coreutils.td/coreutils
>   Try `--no-discard-stderr' if option outputs to stderr
>   prohibit_inttostr_without_use
>   prohibit_jm_in_m4
>   make: *** [man/coreutils.1] Error 127
>   make: *** Waiting for unfinished jobs
> 
> This only goes away without -j here.

Oops, all that was missing for that case was
an entry for coreutils.1 in the static dependency list.
Pity we can't use a GNU pattern rule here,
and portable suffix rules can't have prerequisites.
Note pattern rules seem widely supported, which is tempting.

Anyway I added coreutils.1 to the list and pushed.

thanks for the review,
Pádraig.

bug#18506: stty dsusp undef fails.

[Pádraig Brady]

On 09/19/2014 07:45 PM, Bernhard Voelker wrote:
> On 09/19/2014 05:19 PM, Pádraig Brady wrote:
>> From be1e555db9cfd7e82a0a26e1a612a65ebe93d789 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
>> Date: Fri, 19 Sep 2014 16:15:04 +0100
>> Subject: [PATCH] stty: only list supported options in --help and man pages
>>
>> * src/stty.c (usage): Exclude unsupported options from --help,
>> which only impacts the "dsusp" option on GNU/Linux.
> 
> that one, too:
> 
> -* [\-]cdtrdsr
> -enable DTR/DSR handshaking
> -.TP

Oh right, I was comparing against an older stty without that support.

> A slightly different idea: as this can only happen for non-POSIX
> options, we could change the '*' symbol to e.g. 'S' ("supported
> non-POSIX option) and 'U' (unsupported non-POSIX option).
> WDYT?

I did think about that, but err'd on side of
less information, rather than more.

> The cleanest solution probably would be to distinguish between
> distinguish "invalid argument" from "not supported" errors, as you
> aleady said. I'm not sure if it's worthwhile.

I thought of that too, but thought the doc changes enough.

I'll sleep on this one before pushing.

thanks for all the reviews!

Pádraig.

bug#18386: logname fails with error "logname: no login name" (is there an echo in here)

[Linda Walsh]

Linda Walsh wrote:


I do not have auditing nor selinux incorporated, nor do
I really want to.

Seems like glibc relying on having a specific security model
loaded would seem to be a bug.

I.e. It should work on normal linux security without extra
security modules configed.


   BTW, FWIW, including audit in the kernel enables this
command to work, though "who" is still snafu'd...
That's a more complicated issue as not only has
the login table moved, but it's maintenance has been moved
to systemd...

Would have been nice if they'd updated the standalone version to
work and had systemd use that, but .. it's part of the
systemd-lockin-mentality.