Bug#397046: fslint: [INTL:sv] Swedish translation updated

[Pádraig Brady]

Daniel Nylander wrote:
> Package: fslint
> Severity: wishlist
> Tags: patch l10n
> 
> 
> Here is the updated Swedish translation for fslint.
> I was unable to find the mail address to the author on his webpage

Thanks very much! I'll merge that in ASAP.
Note http://www.pixelbeat.org/fslint/ has
a link for bugs, and my email address is on
the bottom left.

cheers,
Pádraig.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#413907: please enhance fslint's description so it will be easier to find in synaptic

[Pádraig Brady]

Jason Spiro wrote:
> Package: fslint
> Version: 2.16-1
> Severity: trivial
> 
> I wanted a GTK disk space cleaning tool.  But Synaptic couldn't find
> me one.  (I had searched in synaptic for the term: disk space)
> 
> All I found was kleansweep, which is KDE-based.  It would be great if
> you enhanced fslint's description to something longer like this so
> that it'd be easier to find with synaptic's search function:

This is fixed in version 2.20 (which is currently waiting
in mentors.debian.org for uploaded). The new description is:

 A utility to fix problems with filesystems' data, like duplicate files

 FSlint is a toolkit to clean filesystem lint. It includes a GTK+ GUI
 as well as a command line interface and can be used to reclaim disk space.
 It has an interface for uninstalling packages, and it can find things like:
 .
- Duplicate files
- Problematic filenames
- Temporary files
- Bad symlinks
- Empty directories
- Nonstripped binaries


cheers,
Pádraig.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#245017: some notes

[Pádraig Brady]

Just a few points that I figured out about running tftp-hpa on sarge
which were not explained in the bug.

The tftpd-hpa man page states that "the server should be set
to run as the user with the lowest possible privilege"
It's OK (and necessary) to get inetd to run in.tftpd as root though,
as in.tftpd will itself change user to "nobody" by default,
or to whatever is passed in the -u argument.

A quick note on file permissions is that
tftp by default doesn't allow creating files and only
allows writes to existing files when o+w set.

A separate thing I noticed that the '-l' option was specified in
/etc/default/tftpd-hpa?
This is standalone (listen) mode, which would conflict with the server
started by inetd?

Pádraig.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393283: RFC: change chown *not* to look up numeric user/group names

[Pádraig Brady]

Jim Meyering wrote:
> In , Helge Hafting objected to the fact
> that GNU chown performs a DB look-up for a numeric "user name", e.g., in
> "chown 0 FILE".  chown does this deliberately, in case "0" is an actual
> user *name*, that is associated potentially, with some numeric user ID.
> That is the historical behavior, and it is required for POSIX conformance.
> 
> Yes, that does sound silly, if not downright wrong.  Who actually uses
> numeric user or group names these days?  Of the systems that still allow
> such names, how many actually require or even use that capability?

I can see this as being quite common.
Consider a university server.
In my uni all our accounts were 8 digit numbers.

Pádraig.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393283: RFC: change chown *not* to look up numeric user/group names

[Pádraig Brady]

Andreas Schwab wrote:
> Michael Stone <[EMAIL PROTECTED]> writes:
> 
> 
>>I guess it's a case of "numeric usernames are stupid" vs "will it break
>>something". I don't see much reason *not* to be posix compliant in this
>>case, though.
> 
> 
> Perhaps there should just be an option to force the numeric name to be
> interpreted as a number.

Yes I agree with this solution.
But the problem is a startup config error as far as I can see.
No point in adding an option to work around this.
What chown does at present is correct IMHO.

Pádraig.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393283: RFC: change chown *not* to look up numeric user/group names

[Pádraig Brady]

Jim Meyering wrote:
> Do you know if they still do that?

Just checked and yes they do.

Also it was mentioned on a local list that
mobile phone companies all over the world
that use Linux as a messaging platform,
use the mobile number as the username.

> 
> If numeric user names are still common enough, a compromise would be
> to add a configure-time option to enable one behavior or the other,
> and new options:
> 
>   --lookup-numeric
>   --no-lookup-numeric
> 
> Or maybe -- easiest of all -- just don't change anything :-)

I wouldn't change it.

Pádraig.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#738526: sort: weird(might wrong) sorting result

[Pádraig Brady]

On 02/10/2014 08:56 AM, Adam Lee wrote:
> echo -e "c  = c\nca = ca\ncm = cm"|sort

$ echo -e "c  = c\nca = ca\ncm = cm"| LANG=C sort
c  = c
ca = ca
cm = cm

This is a FAQ, but you need to explicitly set the C locale
to avoid your locale collating rules.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723740: should be an Architecture: all package

[Pádraig Brady]

It's just python so should be Architecture: all ?

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728420: fslint: Please add an actual "Size" column in GUI and allow sorting by clicking column headers

[Pádraig Brady]

On 11/01/2013 01:36 AM, user wrote:
> Package: fslint
> Version: 2.42-2
> Severity: wishlist
> Tags: upstream
> 
> Dear Maintainer,
> 
> I would love it if there was a way to sort the results of a dupe scan, perhaps
> by Wasted Space (per group - would be blank for individual files) and plain
> File Size for each file (likely also attached to each file group heading).

> Mostly sorting by the first thing, though - total wasted space per group -
> would be immensely useful.

The sort order of the presented groups should be
"most wasted space first". We'll need to fix that
if it's not working for you. Can you present example
output that shows the unsorted groups?

> I imagine it working like column sorting in Thunar, or many other 
> applications.
> Click the column header and it toggles between ascending sort, descending 
> sort,
> and default order.
> 
> Thank you so much for a great program!

Now the sorting of dupes is a bit restricted,
as the subsequent operations work within
the displayed groups.

I suppose you could also present an option to
"sort by file size" though I don't see that much
need to provide that functionality TBH.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730779: please include coreutils realpath

[Pádraig Brady]

Package: coreutils
Version: 8.21

The coreutils package currently removes the realpath(1) program
in preference for the separate realpath package.
I would encourage biasing towards coreutils realpath instead,
since it has been designed to be fully backwards compat
with the existing realpath program and also has additional features.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751696: coreutils: dd seems to ignore the documented status=xfer option

[Pádraig Brady]

On 06/15/2014 06:10 PM, Roman Czyborra wrote:
> Package: coreutils
> Version: 8.13-3.5
> Severity: normal
> 
> Dear Michael,
> 
> I would expect "suppress transfer statistics" to do away with the "records 
> in" at successful operation:

The records count is a POSIX specified output that _shall_ be output.
One can only control the non POSIX transfer statistics with status=noxfer.
Since coreutils 8.20 there is the new status=none option to suppress all
info and warning messages.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741194: fslint: Find whole directories with duplicate contents

[Pádraig Brady]

On 03/09/2014 09:16 PM, David Z wrote:
> Package: fslint
> Version: 2.42-2
> Severity: wishlist
> Tags: upstream
> 
> I know it would be a lot of work.
> 
> BUT -
> 
> It would be amazing if FSLint output duplicate information by directory.
> 
> For instance, I might have two dirs, "~/Documents/linux guides" and
> "~/Downloads/completed torrents/linux guides torrent". Let's say there is a 
> lot
> of redunandcy of file contents between these directories - perhaps they're
> exact duplicates, or maybe all the files in one of the dirs exists in the
> other, which also has some additional files.
> 
> It would be immensely useful if FSLint could recognize an entire DIRECTORY as
> being redundant. This would speed up file cleanup operations enormously. As it
> stands now, this is most of what I do with FSLint, and I primarily do it with
> md5sum in the terminal after I see file duplicates in two directories that I
> know are both "sets" of files.
> 
> If FSLint could highlight full directories as having their contents exist
> entirely in another directory, it would only take a moment to delete the
> redundant directory, with no additional checks necessary. I would love to see
> this feature!
> 
> Thank you all so much for all your work on this wonderful program!

This is useful and already tracked at:
http://code.google.com/p/fslint/issues/detail?id=25

I've not got time to implement it at present though.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749063: docker makes df horrible

[Pádraig Brady]

On 05/23/2014 04:13 PM, Joey Hess wrote:
> Package: docker.io, coreutils
> Severity: minor
> 
> docker mounts stuff under a directory that normal users cannot read,
> which makes df full of errors. Example below from a system with 4
> running containers.
> 
> I feel this is a polish/integration issue that would be worth finding
> some fix for. At least so far, I have not seen any value in df showing
> these mount points to root, so perhaps they should be completly omitted
> for clarity?

Does `df -a` not show them for root?
Perhaps the duplicate suppression is kicking in here,
though one might have to have root access to determine
the mount points were duplicates.

> 
> See also: #693853, which would apparently fix this, since all the docker
> mounts seem to be find mounts (but I'm not sure how this aufs stuff works).
> 
> df: 
> ‘/var/lib/docker/aufs/mnt/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650’:
>  Permission denied
> df: 
> ‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root’:
>  Permission denied
> df: 
> ‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/.dockerinit’:
>  Permission denied
> ...
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda138G   29G  7.1G  81% /
> udev 10M 0   10M   0% /dev
> tmpfs   397M  184K  397M   1% /run
> tmpfs   5.0M 0  5.0M   0% /run/lock
> tmpfs   1.2G  3.8M  1.2G   1% /run/shm
> cgroup  2.0G 0  2.0G   0% /sys/fs/cgroup
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749063: docker makes df horrible

[Pádraig Brady]

On 05/23/2014 04:49 PM, Michael Stone wrote:
> On Fri, May 23, 2014 at 04:22:04PM +0100, Pádraig Brady wrote:
>> Does `df -a` not show them for root?
>> Perhaps the duplicate suppression is kicking in here,
>> though one might have to have root access to determine
>> the mount points were duplicates.
> 
> Yeah, this is longstanding behavior that's been mildly annoying for years in 
> situations which were previously uncommon but perhaps becoming more 
> common--basically, df tries to stat the mount and spits out an error if it 
> can't. I guess the question is whether there's any point in reporting a 
> permission denied error if a non-root user can't read a mountpoint?
> 
> I see a couple of possible approaches:
> 
> 1) just silently ignore permission denied messages. if root wanted the user 
> to see the mount point, root would have changed the permissions.
> 
> 2) don't print a permission denied message but instead add a partial listing 
> to the output (suppressed without -a) with something like
> [permission_denied] - - - - /mnt/whatever

Ok I'm in the process of fixing up various df edge case issue,
so I'll roll a fix for this into that set in the about
to be released 8.23 upstream release.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747474: coreutils: rm --preserve-root failure

[Pádraig Brady]

On 05/09/2014 08:02 AM, Jessica K. Litwin wrote:
> Package: coreutils
> Version: 8.13-3.5
> Severity: normal
> 
> Dear Maintainer,
> 
> In root-dev-ino.h there is logic to prevent the user from doing
> (for example) 'rm -rf /' without --no-preserve-root. It doesn't
> prevent the user from doing 'rm -rf /*'.  I can't think of any
> reason why the two should be treated differently; I humbly
> suggest patching root-dev-ino.h so that rm balks if instructed
> to 'rm -rf /*' without --no-preserve-root. 
> 
> -- System Information:
> Debian Release: 7.5

While the effect is the same, 'rm -rf /*' is a more explicit request.
The 'rm -rf /' protection is really a protection against inadvertent
spacing as in 'rm -rf / tmp/blah'.  So this proposed additional second
guessing of the user would not be viable upstream.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747474: coreutils: rm --preserve-root failure

[Pádraig Brady]

On 05/09/2014 05:15 PM, Jessica Litwin wrote:
> Hi,
> 
> Can you honestly tell me there is a use case for allowing 'rm -rf /*' to 
> succeed? If we're going to say that it's dangerous to operate on / then it 
> makes sense to trap /* as well. It doesn't make sense that we should allow 
> the root of the filesystem to be destroyed without this protection just on 
> the say-so of an extra character.

Note rm doesn't see the '*'
So you're asking that we disallow: `rm -rf /bin /boot /tmp /usr /var /dev /etc 
/sys ...`
Note practical I'm afraid.
Also that extra '*' character is much less likely to be typed in error.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#739752: bug#17010: Bug#739752: coreutils: ln segfaults when run with --relative and an empty target

[Pádraig Brady]

On 03/14/2014 01:42 AM, Jim Meyering wrote:
> From a6d2db8b6dfe15344aba4aefe9545eb3a4876d45 Mon Sep 17 00:00:00 2001
> From: Jim Meyering 
> Date: Thu, 13 Mar 2014 17:05:04 -0700
> Subject: [PATCH] ln: with -sr, don't segfault for a TARGET of ''
> 
> Prior to this change, "ln -sr '' F" would segfault, attempting
> to read path2[1] in relpath.c's path_common_prefix function.
> This problem arises whenever canonicalize_filename_mode returns
> NULL.
> * src/ln.c (convert_abs_rel): Call relpath only when
> both canonicalize_filename_mode calls return non-NULL.
> * tests/ln/relative.sh: Add a test to trigger this failure.
> * THANKS.in: List reporter's name/address.
> * NEWS (Bug fixes): Mention it.
> Reported by Erik Bernstein in 739...@bugs.debian.org.

We can amend with the now allocated:

  Fixes http://bugs.gnu.org/17010

> diff --git a/NEWS b/NEWS
> index 62966b2..b3ad65c 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -25,6 +25,8 @@ GNU coreutils NEWS-*- 
> outline -*-
>it would display an error, requiring --no-dereference to avoid the issue.
>[bug introduced in coreutils-5.3.0]
> 
> +  ln -sr '' F no longer segfaults: now it fails with the expected diagnostic

Probably should add:

 [bug introduced with the --relative feature in coreutils-8.16]

> diff --git a/src/ln.c b/src/ln.c
> index aab9cf2..6726699 100644
> --- a/src/ln.c
> +++ b/src/ln.c
> @@ -149,13 +149,17 @@ convert_abs_rel (const char *from, const char *target)
>char *realdest = canonicalize_filename_mode (targetdir, CAN_MISSING);
>char *realfrom = canonicalize_filename_mode (from, CAN_MISSING);

Interesting. So canonicalize_filename_mode() can fail in this case,
even with CAN_MISSING. It's unexpected that c_f_m() sets errno=ENOENT
when CAN_MISSING is set. I wonder should we change that instead
in gnulib? With CAN_MISSING I would expect this function to work
on arbitrary strings, including the empty string.

> 
> -  /* Write to a PATH_MAX buffer.  */
> -  char *relative_from = xmalloc (PATH_MAX);
> -
> -  if (!relpath (realfrom, realdest, relative_from, PATH_MAX))
> +  char *relative_from = NULL;
> +  if (realdest && realfrom)
>  {
> -  free (relative_from);
> -  relative_from = NULL;
> +  /* Write to a PATH_MAX buffer.  */
> +  relative_from = xmalloc (PATH_MAX);
> +
> +  if (!relpath (realfrom, realdest, relative_from, PATH_MAX))
> +{
> +  free (relative_from);
> +  relative_from = NULL;
> +}
>  }
> 
>free (targetdir);

> diff --git a/tests/ln/relative.sh b/tests/ln/relative.sh
> +# Expect this to fail with exit status 1.
> +# Prior to coreutils-8.23, it would segfault.
> +ln -sr '' F
> +test $? = 1 || fail=1

Won't the ln succeed on FreeBSD as per:
http://bugs.gnu.org/13447

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#739752: bug#17010: Bug#739752: coreutils: ln segfaults when run with --relative and an empty target

[Pádraig Brady]

On 03/14/2014 03:44 AM, Jim Meyering wrote:
> On Thu, Mar 13, 2014 at 7:22 PM, Pádraig Brady  wrote:

>> Interesting. So canonicalize_filename_mode() can fail in this case,
>> even with CAN_MISSING. It's unexpected that c_f_m() sets errno=ENOENT
>> when CAN_MISSING is set. I wonder should we change that instead
>> in gnulib? With CAN_MISSING I would expect this function to work
>> on arbitrary strings, including the empty string.
> 
> What would you have c_f_m("", CAN_MISSING) return?
> I know of no absolute name corresponding to the dot-relative empty string.

Since with CAN_MISSING we should be just degenerating to string processing,
I would think it slightly better to return xstrdup(""),
to avoid special casing that in each caller.

I also notice that c_f_m() can return ENOMEM (from areadlink_with_size).
It's arguable that we should xalloc_die() within c_f_m()
for consistency in that case.

However I also notice that c_f_m("", CAN_MISSING) can return ENOENT
if the current working dir is unlinked.  I'm not sure
there is anything else we could do within c_f_m() to handle that.

Hence since c_f_m() can validly fail even with CAN_MISSING,
I agree your patch is correct.

Please push.

thanks!
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730779: realpath maintainer also wants to switch to the GNU coreutils version

[Pádraig Brady]

Referencing Rober's request to switch to the GNU coreutils version,
which by design was meant to be as close as possible to the Debian version:
https://lists.debian.org/debian-embedded/2013/12/msg2.html

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682969: timeout 20 /usr/sbin/ntpd -g -q gives wrong return code

[Pádraig Brady]

On 07/27/2012 05:56 PM, Jim Meyering wrote:
> Goswin von Brederlow wrote:
>> Package: coreutils
>> Version: 8.13-3.2
>> Severity: normal
>> File: /usr/bin/timeout
>>
>> I'm trying to set the time during boot. Unfortunately ntpd hangs forever
>> if the timeserver is unavailable. So I added a timeout to it so the
>> system still continues to boot without the correct time.
>>
>> But I would like to log the error. Timeout is supposed to return 124 if the
>> time was exceeded. But if ntpd corrects the time by more than the timeout
>> then the return value is 124 despite the fact the real time passed was less.
>>
>> Wouldn't it be possible to detect this case and return the exit code of
>> ntpd instead of a false timeout error?
> 
> Thanks for the report.
> Did you experience an actual problem?
> 
> When I try to trigger such misbehavior, timeout seems to work fine
> on a system (Fedora 17) with a working timer_settime function:
> 
> $ timeout 2 date --set=$(LC_ALL=C date -d 10\ sec +@%s); echo $?
> 0
> 
> I.e., when timeout's child terminates, the clock says
> 10 seconds have elapsed, yet it exits 0, because the
> duration was less than 2 seconds.
> 
> I'm using the timeout from coreutils-8.17, but nothing
> has changed in this area since before 8.13.
> 
> I even rebuilt my timeout binary, simulating no timer_settime
> function so that it would take the alarm-using path.  Same result.

Note timeout(1) currently uses timer_create(CLOCK_REALTIME).
That could jump and cause signals to fire.
Though I can't reproduce here, even when pushing the
updated system clock down to the hardware:

# timeout 3 sh -c 'date --set=$(LC_ALL=C date -d 10\ sec +@%s); hwclock -w; 
sleep 1'
# echo $?
0

I was wondering about using CLOCK_MONOTONIC instead,
though I'd need to test how that functions over a suspend/resume.
I suspect it only counts up while the system is running.
Maybe we should default to system running time, rather than
wall clock time, though then we'd have to look at/document
the inconsistency on systems without CLOCK_MONOTONIC.

Goswin what's the output from uname -a
as a matter of interest?

cheers,
Pádraig.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Pádraig Brady]

On 09/07/2012 11:35 AM, Niels Möller wrote:

Pádraig Brady  writes:


On 09/07/2012 09:43 AM, Niels Möller wrote:



If this is an important feature, maybe one should consider bundling
mini-gmp



Bundling libraries is bad if one needed to update it.


mini-gmp is not an ordinary library. It's a single portable C source
file (currently around 4000 lines) implementing a subset of the GMP API,
and with performance only a few times slower than the real thing, for
"small bignums". It's *intended* for bundling with applications, either
for unconditional use, or for use as a fallback if the real gmp library
is not available. It's never (I hope!) going to be installed in
/usr/lib. To me, coreutil's factor seem to be close match for what it's
intended for.

That said, mini-gmp is pretty new (I wrote most of it around last
Christmas) and I'm not aware of any application or library using it yet.
I think the guile hackers are considering using it (for the benefit of
applications which use guile as an extension language, but don't need
high performance bignums).

So if you decide to use it in coreutils, you'll be pioneers.

It *is* used in the GMP build process, for precomputing various internal
tables.


I can see the need when bootstrapping,
but I'd prefer if coreutils just relied on regular GMP.

That said, I see there is some push back in debian on depending on GMP.
Note expr from coreutils also uses GMP, which may sway the decision.

thanks,
Pádraig.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702968: /usr/share/fslint/fslint/findup: always finds duplicates

[Pádraig Brady]

On 03/13/2013 02:23 PM, Michal Suchanek wrote:
> Package: fslint
> Version: 2.42-2
> Severity: normal
> File: /usr/share/fslint/fslint/findup
> 
> Hello,
> 
> /usr/share/fslint/fslint/findup -t /srv/mail
> 
> prints a lot of duplicates.
> 
> /usr/share/fslint/fslint/findup -m /srv/mail
> 
> does something.
> 
> /usr/share/fslint/fslint/findup -t /srv/mail
> 
> still finds duplicates (maybe fewer).
> 
> Isn't the directory supposed to be deduplicated?
> 
> Sure, a process writing new file could cause more duplicates but this is
> not the case.
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (800, 'stable'), (400, 'unstable'), (200, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages fslint depends on:
> ii  findutils  4.4.2-4
> ii  python 2.7.3~rc2-1
> ii  python-glade2  2.24.0-3+b1
> ii  python-gtk22.24.0-3+b1
> 
> fslint recommends no packages.
> 
> fslint suggests no packages.
> 
> -- no debconf information

If there are hardlinks already in /srv/mail you may be hitting:
http://code.google.com/p/fslint/issues/detail?id=70

Does the fslint-gui report duplicates, as it has
extra processing to avoid reporting hardlinks.

thanks,
Pádraig.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#713022: bug#14686: Bug#713022: truncate man and info pages must mention -s / -r mandatory

[Pádraig Brady]

On 06/21/2013 09:05 PM, jida...@jidanni.org wrote:
> Package: coreutils
> Version: 8.13-3.3
> File: /usr/share/man/man1/truncate.1.gz
> X-debbugs-CC: bug-coreut...@gnu.org
> 
> $ truncate /tmp/erere
> truncate: you must specify either `--size' or `--reference'
> 
> What a shock. Not mentioned on man or info pages!

Well it was immediately obvious what to do given the above output.
Some might consider a pointed message like this,
preferable to having to read the manual initially.

> 
> And
>truncate OPTION... FILE...
> should be
>truncate <--size|--ref...>  [OPTION...] FILE...

Or more accurately:

 truncate <--size|--reference>  [OPTION...] FILE...

Now some may find the above more confusing to parse.
Also worth noting is the next line in the man page and info manual,
i.e. the first line of the description, should make it quite obvious
a size is required:

  "Shrink or extend the size of each FILE to the specified size"

Also we follow this pattern for other utils like cut(1).

So I'm slightly inclined to leave as is.

> Also mention size is in bytes. Don't just hope the reader will examine
> every options' wording to ferret that out.

Fair enough. I'll adjust to:

  -s, --size=SIZE
  set or adjust the file size by SIZE bytes.  See also --io-blocks

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#713022: bug#14686: Bug#713022: truncate man and info pages must mention -s / -r mandatory

[Pádraig Brady]

On 06/22/2013 09:42 AM, jida...@jidanni.org wrote:
> I thought it would do the obvious, like touch does.
> 
> 
> NAME
>touch - change file timestamps
> 
> SYNOPSIS
>touch [OPTION]... FILE...
> 
> DESCRIPTION
>Update  the  access  and modification times of each FILE to the current
>time.
> 
>A FILE argument that does not exist is created empty, unless -c  or  -h
>is supplied.
> 
> 
> 
> NAME
>truncate - shrink or extend the size of a file to the specified size
> 
> SYNOPSIS
>truncate OPTION... FILE...
> 
> DESCRIPTION
>Shrink or extend the size of each FILE to the specified size
> 
>A FILE argument that does not exist is created.
> 
> 
> 
> Who would have guessed that for some reason an argument is required,
> I don't see why
> $ truncate FILE
> cannot just work too.
> You know, to truncate the file, to zero bytes.
> But hey I'm not a pro.

I remember discussing the interface at the time.
The thinking was that since data was destroyed here,
an explicit -s0 was required to avoid typos like:

  truncate - s1M file

Behaving like you suggest would create '-' and 's1M'
and truncate 'file' without warning.

cheers,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718898: cut no longer works with newline as delimiter

[Pádraig Brady]

On 08/06/2013 08:32 PM, Bob Proulx wrote:
> Volker Klasen opened a bug in the Debian bug tracker concerning a
> change in behavior in cut.  I have CC'd the bug on this message.  I
> have manually set an appropriate Reply-To header.
> 
>   http://bugs.debian.org/718898
> 
> There has been a lot of improvements made to cut.  But the issue is
> this one.  In the older 8.13 this was the behavior:
> 
> $ printf "one\ntwo\n" | cut -d "
>> " -f2
> two
> 
> In the newer 8.21 this is the new behavior:
> 
> $ printf "one\ntwo\n" | cut -d "
>> " -f2
> one
> two
> 
> Was this change intentional or accidental?

Intentional. The change in question, to treat each line independently was:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=51ce0bf8
to address: http://bugs.gnu.org/13498

Now there are some edge cases where -d $'\n' might be useful
which I documented through tests in:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=d302aed1

Also if the last line doesn't contain \n, then cut will output a \n.
So if lines weren't treated separately as was the case,
then cut would be outputting a trailing "delimiter" not present in the input.

Also the new behavior aligns with other platforms.
Both coreutils >= 8.21 and FreeBSD at least operate as follows:

$ printf '%s\n' a b | cut -d $'\n' -s -f1
a
b

> P.S. Of course using cut is a terrible way to select the second line.
> I would use "awk 'NR==2'".  But that is a separate issue.

also:
 sed -n '2{p;q}'
 head -n2 | tail -n1
 tr '\n' '\0' | cut -f2 -d $'\0'

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723740: RFP: crudini - A utility for manipulating ini files

[Pádraig Brady]

Package: wnpp
Severity: wishlist

Package name: crudini
Version : 0.3
Upstream Author : Pádraig Brady 
URL : http://www.pixelbeat.org/programs/crudini/
Source URL  : https://github.com/pixelb/crudini/
License : GPLV2
Programming Lang: python

A utility for easily handling ini files from the command line and shell scripts.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#799131: coreutils: df sometimes skips real entry and reports a bind mount instead

[Pádraig Brady]

On 15/09/15 23:21, Nye Liu wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: minor
> 
> Dear Maintainer,
> 
> When using bind mounts, df may have to choose only one of many equivalent
> mounts:
> 
> $ mount
> /dev/sdb1 on /export/real type ext4 (rw,relatime,data=ordered)
> /dev/sdb1 on /home/ type ext4 (rw,relatime,data=ordered)
> /dev/sdb1 on /home/ type ext4 (rw,relatime,data=ordered)
> /dev/sdb1 on /home/ type ext4 (rw,relatime,data=ordered)
> 
> $ df -l
> /dev/sdb1  1921677460 1094613156 729425740  61% /home/
> 
> but it really should report
> $ df -l
> /dev/sdb1  1921677460 1094613156 729425740  61% /export/real
> 
> That said, I am unsure how it should know which one is the "real mount"
> 
> See also
> 
> http://www.linuxquestions.org/questions/slackware-14/coreutils-8-21-'df'-bind-mount-bug-4175453522/
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages coreutils depends on:
> ii  libacl1  2.2.52-1
> ii  libattr1 1:2.4.47-2
> ii  libc62.19-18
> ii  libselinux1  2.3-2
> 
> coreutils recommends no packages.
> 
> coreutils suggests no packages.
> 
> -- debconf-show failed
> 
> 
> MRV Communications is a global supplier of packet and optical solutions that 
> power the world’s largest networks. Our products combine innovative hardware 
> with intelligent software to make networks smarter, faster and more efficient.
> 
> 

We're about to merge logic upstream that incorporates the "root" or 4th
column from /proc/$$/mountinfo.  df will use that to display the mount
closest to the root of the device.

thanks,
Pádraig

Bug#859021: dd: document that bs overrides ibs and obs

[Pádraig Brady]

On 29/03/17 09:04, Chris Davies wrote:
> Package: coreutils
> Version: 8.25-2+b1
> Severity: minor
> 
> Dear Maintainer,
> 
> The man page for dd does not define an interaction between bs and its more
> specific ibs and obs options. POSIX does mandate that bs, if specified,
> shall override ibs and obs. Empirically I have determined that coreutils
> dd implements POSIX behaviour, so I should like to suggest the man page
> is updated to state that bs overrides ibs and/or obs.
> 
> 
> POSIX man page at http://www.unix.com/man-page/posix/1posix/dd/ defines
> the three options bs, ibs, and obs as follows:
> 
> ibs=expr
>   Specify the input block size, in bytes, by expr (default is 512).
> 
> obs=expr
>   Specify the output block size, in bytes, by expr (default is 512).
> 
> bs=expr
>   Set  both input and output block sizes to expr bytes, superseding
>   ibs= and obs=. If no conversion other than sync, noerror, and
>   notrunc is specified, each input  block shall be copied to the
>   output as a single block without aggregating short blocks.
> 
> 
> Extracts from the current coreutils man page read as follows:
> 
> bs=BYTES
>   read and write up to BYTES bytes at a time
> 
> ibs=BYTES
>   read up to BYTES bytes at a time (default: 512)
> 
> obs=BYTES
>   write BYTES bytes at a time (default: 512)
> 
> 
> I would like to suggest that the explanation is amended as follows:
> 
> bs=BYTES
>   read and write up to BYTES bytes at a time (default:
>   512); overrides ibs and obs

Done in your name upstream at:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.27-15-gc1c558e

Bug#806321: coreutils: please make the build reproducible (timestamps)

[Pádraig Brady]

On 26/11/15 13:59, Jérémy Bobbio wrote:
> Source: coreutils
> Version: 8.23-4
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> 
> Hi!
> 
> While working on the “reproducible builds” effort [1], we have noticed
> that coreutils could not be built reproducibly. The build process uses
> help2man to create some of manpages.
> 
> help2man author added support for the SOURCE_DATE_EPOCH environment
> variable [2] in version 1.47.1 which makes it possible to use a
> pre-defined value instead of the time of the build.
> 
> As coreutils source currently contains an old version of help2man, the
> attached patch will copy the version in the help2man Debian package
> before running ./configure on top of setting SOURCE_DATE_EPOCH to the
> date of the latest debian/changelog entry.
> 
> Once applied, coreutils can be built reproducibly in our current
> experimental framework.
> 
>  [1]: https://wiki.debian.org/ReproducibleBuilds
>  [2]: https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal
> 

Note with the soon to be released coreutils 8.25 it will be better to
leave the bundled help2man in place, but continue
to set SOURCE_DATE_EPOCH as you do.

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=c1b3d658

cheers,
Pádraig

Bug#793831: coreutils: stat does not report file birth timestamp, even when available

[Pádraig Brady]

On 28/07/15 00:23, Grant Sanders wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: minor
> 
> Dear Maintainer,
> 
> Stat does not seem to recognize any timestamps for file birth, even when they
> are available and accurate. My filesystem is ext4.
> 
> To reproduce, I ran: touch /root/test. Then I ran: stat /root/test. Output:
> 
> ---
>   File: ‘/root/test’
>   Size: 0   Blocks: 0  IO Block: 4096   regular empty file
> Device: 802h/2050d  Inode: 13  Links: 1
> Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
> Access: 2015-07-27 16:05:42.885356874 -0700
> Modify: 2015-07-27 16:05:42.885356874 -0700
> Change: 2015-07-27 16:05:42.885356874 -0700
>  Birth: -
> ---
> 
> Thereafter I ran: debugfs -R 'stat /root/test' /dev/sda2. Output below:
> 
> ---
> debugfs 1.42.12 (29-Aug-2014)
> Inode: 13   Type: regularMode:  0644   Flags: 0x8
> Generation: 840633321Version: 0x:0001
> User: 0   Group: 0   Size: 0
> File ACL: 0Directory ACL: 0
> Links: 1   Blockcount: 0
> Fragment:  Address: 0Number: 0Size: 0
>  ctime: 0x55b6b946:d315e528 -- Mon Jul 27 16:05:42 2015
>  atime: 0x55b6b946:d315e528 -- Mon Jul 27 16:05:42 2015
>  mtime: 0x55b6b946:d315e528 -- Mon Jul 27 16:05:42 2015
> crtime: 0x55b6b946:d315e528 -- Mon Jul 27 16:05:42 2015
> Size of extra inode fields: 28
> EXTENTS:
> ---
> 
> The crtime (file birth) timestamp is is there and functioning normally. As far
> as I know, this version of stat is supposed to have support for crtime on 
> ext4.
> I have not tested any other filesystem types yet.
> 
> As a side note, I know running as root is a bad idea, but debugfs complained
> when I tried to use it with sudo.
> 
> 
> -- System Information:
> Debian Release: 8.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages coreutils depends on:
> ii  libacl1  2.2.52-2
> ii  libattr1 1:2.4.47-2
> ii  libc62.19-18
> ii  libselinux1  2.3-2
> 
> coreutils recommends no packages.
> 
> coreutils suggests no packages.

There currently is no Linux kernel interface to get creation time:
See upstream issue http://bugs.gnu.org/14703

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#755714: /usr/bin/id: lies about the available groups

[Pádraig Brady]

On 07/22/2014 05:18 PM, Ron wrote:
> Package: coreutils
> Version: 8.21-1.2
> Severity: normal
> 
> Hi,
> 
> The coreutils changelog notes that a bug in id and groups which
> overreported the available groups was supposedly fixed in:
> 
>   2012-04-27  Jim Meyering  
> 
>   id,groups: with no user name, print only real and/or effective IDs,
>   ... i.e., don't use the getpw* functions.
> 
>   Before this change, running groups or id with no user name argument
>   would include a group name or ID from /etc/passwd.  Thus, under unusual
>   circumstances (default group is changed, but has not taken effect for a
>   given session), those programs could print a name or ID that is neither
>   real nor effective.
> 
> 
> However this appears to not be the case for id in jessie.  If it is
> called after only calling setuid(), and not assigning any supplementary
> groups or calling setgid(), then it reports something like:
> 
>  uid=1000(ron) gid=0(root) groups=1000(ron),0(root)
> 
> /usr/bin/groups however now does the right thing in jessie (it had this
> bug in wheezy).
> 
> The id(1) man page is a bit ambiguous about what it should report there,
> but SuSv4 is quite clear that:
> 
>  "If no user operand is provided, the id utility shall write the user
>   and group IDs and the corresponding user and group names of the
>   invoking process to standard output."
> 
> And since the process above was not actually in group 1000, that should
> not have been included.
> 
> Given the changelog entry above, it's not clear to me yet if this is
> a regression upstream, a regression due to a debian patch, or if the
> original fix wasn't actually sufficient.  But this is what I know at
> this stage.
> 
>   Cheers,
>   Ron

I think the above referenced fix was only partial,
and the complete fix should now be in coreutils-8.23 which includes:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=408461c0

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#756712: ls -l should indicate presence of capabilities (just as + indicates ACLs)

[Pádraig Brady]

On 08/01/2014 01:10 AM, Josh Triplett wrote:
> Package: coreutils
> Version: 8.21-1.2
> Severity: normal
> File: /bin/ls
> 
> ls -l indicates a file with ACLs set by putting a + after the permission
> block.  It should have a similar indicator for files that have
> capabilities set (as via setcap).  Such capabilities have
> security implications similar to setuid and setgid, but with fewer
> obvious signs.

Agreed. This is tracked upstream at:
http://bugs.gnu.org/14283


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#786563: df: undocumented option -m

[Pádraig Brady]

tag 786563 wontfix
close 786563
stop

On 22/05/15 22:15, Goswin von Brederlow wrote:
> Package: coreutils
> Version: 8.21-1.2
> Severity: minor
> File: /bin/df
> 
> Hi,
> 
> I just noticed that the df manpage is not mentioning -m.

-m is obsolescent and so undocumented
and only exists for BSD compatibility

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#791921: coreutils: Add tmux, tmux-256colors terminfos to dircolors database

[Pádraig Brady]

On 09/07/15 16:03, Víctor Cuadrado Juan wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: wishlist
> 
> Dear Maintainer,
> 
> The commands depending on 'dircolor' ('ls', 'dir', etc) do not output colors
> when you are using TERM=tmux or TERM=tmux-256color inside of tmux.
> 
> This happens because LS_COLORS is empty when using those terminfos, as
> 'dircolor'
> hasn't populated it:
> - Inside of tmux: 'TERM=screen-256color env | grep LS_COLORS' shows a 
> populated
> LS_COLORS.
> - Inside of tmux: 'TERM=tmux-256color env | grep LS_COLORS' or 'TERM=tmux env 
> |
> grep LS_COLORS' shows LS_COLORS empty.
> 
> Another way to see it:
> - Inside of tmux: 'TERM=screen-256color ls --color' outputs colors.
> - Inside of tmux: TERM=tmux-256color ls --color' or 'TERM=tmux ls --color' 
> does
> not output colors.
> 
> As tmux and tmux-256colors are provided by the ncurses-term Debian package, it
> would be good if they were supported by dircolor, by adding them to
> "src/dircolors.hin".
> 
> I would submit a patch myself, but I'm not sure if this change is only 
> relative
> to Debian sources (does ncurses-term provide terminfos that may not be in 
> other
> distros?)
> or the patch should go with upstream sources (and open another bug upstream
> too).

May be Debian specific?
The following is on Fedora 22:

$ TERM=screen-256color tput colors
256
$ TERM=tmux-256color tput colors
tput: unknown terminal "tmux-256color"

cheers,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#791921: coreutils: Add tmux, tmux-256colors terminfos to dircolors database

[Pádraig Brady]

On 09/07/15 17:09, Michael Stone wrote:
> On Thu, Jul 09, 2015 at 04:38:07PM +0100, Pádraig Brady wrote:
>> May be Debian specific?
>> The following is on Fedora 22:
>>
>> $ TERM=screen-256color tput colors
>> 256
>> $ TERM=tmux-256color tput colors
>> tput: unknown terminal "tmux-256color"
> 
> Fedora will presumably upgrade to newer upstream terminfo that includes 
> the tmux stuff at some point. (It went in 20150502.)
> 
> I'll add it with the next debian upload and it presumably should go in 
> coreutils upstream also.

Done.

> This is a perennial pain, but nobody really 
> wants to do the "right" thing (link coreutils against ncurses and check 
> for color capability at run time).

Yes this could be improved.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792808: coreutils: CRC file checks not consistent

[Pádraig Brady]

On 18/07/15 19:38, Leslie Rhorer wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> CRC checks on large files often return variable values.  I have tried several 
> different CRC check utilities, md5sum, md6sum, sha56sum, etc., and they all 
> exhibit the same behavior.  Multiple runs of the utility on a given file more 
> often than not will return different values for many or all of the attempts.  
> I have only noticed the effect on large files, but I cannot say with 
> authority it only happens on large files.  I noticed the effect when checking 
> file integrity between identical files on two different systems.  The backup 
> server is running Squeeze, and checks on the files of that system are 
> consistent, but when comparing the CRC between that system and the primary, 
> which is running Jessie, the checks often failed.  At first I of course 
> thought this indicated file corruption on one server or the other, beut when 
> I started investigating, I discovered sometimes the results were different on 
> the two systems and sometimes the same.  At that point I discovered it was 
> only th!
>  e machine running Jessie that was producing inconsistent results.  At first 
> I thought I was having problems with the file system (and indeed I am, as it 
> happens), but when I copied one of the large files over to a different file 
> system, the problem perissts.  One is an XFS file system (the one having the 
> problems) and the other is an Ext4 file system.
> 
> Note this impacts a great many very important procedures and utilities, 
> including my backup and compare strategy using rsync, file systems checks, 
> etc.
> 
> RAID-Server:/# sha256sum "/RAID/Recordings/Abyss, The (Recorded Thu Sep 11, 
> 2014, MAXHD).mp4"
> b2e15ca178832e9f12a4823c583eefb2028cec9f7c45f36ea9dfa2297c904d6d  
> /RAID/Recordings/Abyss, The (Recorded Thu Sep 11, 2014, MAXHD).mp4
> RAID-Server:/# sha256sum "/RAID/Recordings/Abyss, The (Recorded Thu Sep 11, 
> 2014, MAXHD).mp4"
> eb3067b250d5d16e1d5d3f2b328001be91c4e5107a14e0010940acdab6584f2b  
> /RAID/Recordings/Abyss, The (Recorded Thu Sep 11, 2014, MAXHD).mp4
> RAID-Server:/# sha256sum "/RAID/Recordings/Abyss, The (Recorded Thu Sep 11, 
> 2014, MAXHD).mp4"
> 6eddb4174b49e9bac741070559ad159acaa39a404a1b75c395d716910e5c81ef  
> /RAID/Recordings/Abyss, The (Recorded Thu Sep 11, 2014, MAXHD).mp4


The inconsistent results are restricted to the Jessie system?
I'd run memtest given results like that.
Also I'd verify a separate checksum implementation.
I don't think debian configures coreutils --with-openssl
so this should be independent:

  openssl md5 largefile

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#785118: coreutils: date : format %p %P do not work properly

[Pádraig Brady]

On 12/05/15 16:40, Pádraig Brady wrote:
> On 12/05/15 14:51, Michael Stone wrote:
>> On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote:
>>> I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) 
>>> and several of my scripts are not working anymore. After some tests, it 
>>> turns out that the problem likely comes from the fact the 'date' function 
>>> does not work as expected.
>>>
>>> In wheezy, the command line
>>>> date /bin/date +"%Y%m%d.%p"
>>> would have returned
>>>> 20150512.PM
>>>
>>> In jessie, the same command line returns
>>>> 20150512.
>>> omitting PM.
>>>
>>> As a consequence of this omission, my scripts are crashing.
>>>
>>> Have you got any idea why this is happening?
>>
>> I can't reproduce it:
>>
>>> /bin/date +"%Y%m%d.%p"
>> 20150512.AM
>>
>> If I had to guess, I'd say it's a locale issue. What does 
>> env LANG=C LC_ALL=C /bin/date +"%Y%m%d.%p"
>> return?
>>
>> If that works, what does 
>> locale
>> return when run by itself?
> 
> %p is blank in many locales unfortunately.
> You can see the am_pm vary with these commands:
> 
> $ LC_ALL=en_IE locale -k LC_TIME
> $ LC_TIME=C locale -k LC_TIME
> $ LC_ALL=zh_CN.utf8 date +%p
> 下午
> $ LC_ALL=en_US.utf8 date +%p
> PM
> $ LC_ALL=en_US date +%p
> PM
> 
> locales with blank am_pm should be fixed up to allow one to
> get an explicit 12 hour format like `date +%I:%m%p` for example.
> 
> Note some locales (like en_GB for example) default
> to 24 hour (t_fmt="%T"), and also provide an am_pm entry,
> which is the correct behavior in my opinion.

I see that https://sourceware.org/glibc/wiki/Locales states:
"am_pm and t_fmt_ampm - should be empty if using 24 hour time"

Marko, that seems incorrect?
At least am_pm should be populated to
allow users to generate 12 hour time with strftime?

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#785118: coreutils: date : format %p %P do not work properly

[Pádraig Brady]

On 12/05/15 17:55, Marko Myllynen wrote:
> Hi,
> 
> [CC'ing Keld with whom this issue was discussed some years ago]
> 
> On 2015-05-12 18:49, Pádraig Brady wrote:
>> On 12/05/15 16:40, Pádraig Brady wrote:
>>> On 12/05/15 14:51, Michael Stone wrote:
>>>> On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote:
>>>>> I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) 
>>>>> and several of my scripts are not working anymore. After some tests, it 
>>>>> turns out that the problem likely comes from the fact the 'date' function 
>>>>> does not work as expected.
>>>>>
>>>>> In wheezy, the command line
>>>>>> date /bin/date +"%Y%m%d.%p"
>>>>> would have returned
>>>>>> 20150512.PM
>>>>>
>>>>> In jessie, the same command line returns
>>>>>> 20150512.
>>>>> omitting PM.
>>>>>
>>>>> As a consequence of this omission, my scripts are crashing.
>>>>>
>>>>> Have you got any idea why this is happening?
>>>>
>>>> I can't reproduce it:
>>>>
>>>>> /bin/date +"%Y%m%d.%p"
>>>> 20150512.AM
>>>>
>>>> If I had to guess, I'd say it's a locale issue. What does 
>>>> env LANG=C LC_ALL=C /bin/date +"%Y%m%d.%p"
>>>> return?
>>>>
>>>> If that works, what does 
>>>> locale
>>>> return when run by itself?
>>>
>>> %p is blank in many locales unfortunately.
>>> You can see the am_pm vary with these commands:
>>>
>>> $ LC_ALL=en_IE locale -k LC_TIME
>>> $ LC_TIME=C locale -k LC_TIME
>>> $ LC_ALL=zh_CN.utf8 date +%p
>>> 下午
>>> $ LC_ALL=en_US.utf8 date +%p
>>> PM
>>> $ LC_ALL=en_US date +%p
>>> PM
>>>
>>> locales with blank am_pm should be fixed up to allow one to
>>> get an explicit 12 hour format like `date +%I:%m%p` for example.
>>>
>>> Note some locales (like en_GB for example) default
>>> to 24 hour (t_fmt="%T"), and also provide an am_pm entry,
>>> which is the correct behavior in my opinion.
>>
>> I see that https://sourceware.org/glibc/wiki/Locales states:
>> "am_pm and t_fmt_ampm - should be empty if using 24 hour time"
>>
>> Marko, that seems incorrect?
>> At least am_pm should be populated to
>> allow users to generate 12 hour time with strftime?
> 
> I can't find references to the discussion I had with Keld earlier but
> the rationale for not populating it was along the lines:
> 
> 1) am_pm should be populated only if AM/PM convention is used to signal
> applications they should not try to print them when using them is
> unwanted. Seems that only the locale(5) commit messages, not the page
> itself, spell this out:
> 
> http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=b5d4168adfb426f45108ac2bf7c8b17b126b07a1
> http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=0c2dbad182e40db2ca47128f229ca7dbd83e179f
> 
> 2) what "unwanted" means is that in many cases 12 hour time with AM/PM
> notation is alien thus generating such time representation under those
> locales would be illogical (e.g. "5.34 ip." in Finnish context is
> completely unnatural).
> 
> The same goes for various name_* keywords in LC_NAME, defining them for
> locales where they are not used would not allow signaling applications
> that under those locales their usage is unwanted.

Thanks for the info.

Generally apps would not need to know whether to select
between 12 and 24?  Can't they just use the higher level
(and POSIX defined) %X to get the appropriate default?

I propose the wiki at least should be reworded to
state that am_pm should be omitted only when
it doesn't make any sense, like in Finland for example?

Also we'll need to fix up some locales that may have
blindly followed the existing advice.

The 12h format is not appropriate for Ireland at least:

$ LC_TIME=en_IE date +'def: %X | 12h: %r | 24h: %T'
def: 18:19:52 | 12h: 06:19:52  | 24h: 18:19:52

cheers,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#785118: coreutils: date : format %p %P do not work properly

[Pádraig Brady]

On 12/05/15 14:51, Michael Stone wrote:
> On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote:
>> I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and 
>> several of my scripts are not working anymore. After some tests, it turns 
>> out that the problem likely comes from the fact the 'date' function does not 
>> work as expected.
>>
>> In wheezy, the command line
>>> date /bin/date +"%Y%m%d.%p"
>> would have returned
>>> 20150512.PM
>>
>> In jessie, the same command line returns
>>> 20150512.
>> omitting PM.
>>
>> As a consequence of this omission, my scripts are crashing.
>>
>> Have you got any idea why this is happening?
> 
> I can't reproduce it:
> 
>> /bin/date +"%Y%m%d.%p"
> 20150512.AM
> 
> If I had to guess, I'd say it's a locale issue. What does 
> env LANG=C LC_ALL=C /bin/date +"%Y%m%d.%p"
> return?
> 
> If that works, what does 
> locale
> return when run by itself?

%p is blank in many locales unfortunately.
You can see the am_pm vary with these commands:

$ LC_ALL=en_IE locale -k LC_TIME
$ LC_TIME=C locale -k LC_TIME
$ LC_ALL=zh_CN.utf8 date +%p
下午
$ LC_ALL=en_US.utf8 date +%p
PM
$ LC_ALL=en_US date +%p
PM

locales with blank am_pm should be fixed up to allow one to
get an explicit 12 hour format like `date +%I:%m%p` for example.

Note some locales (like en_GB for example) default
to 24 hour (t_fmt="%T"), and also provide an am_pm entry,
which is the correct behavior in my opinion.

cheers,
Pádraig


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784105: coreutils: df show /dev/dm-0 instead /dev/mapper/XXX

[Pádraig Brady]

On 03/05/15 08:16, Rabin Yasharzadehe wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: important
> 
> Dear Maintainer,
> 
>> What led up to the situation?
> After the upgrade to Debian 8 from Debain 7, 
> the output of the df command have changed.
> 
> This change broke oue backup scripts which was looking for
> the mapper string in the df command output.
> 
>> Old out put format was 
> 
> # df -Ph /
> FilesystemSize  Used Avail Use% Mounted on
> /dev/mapper/vg1-root   14G  3.3G  9.8G  25% /
> 
>> New (bad) output 
> 
>  # df -Ph /
>  Filesystem  Size  Used Avail Use% Mounted on
>  /dev/dm-0   6.7G  3.6G  2.8G  57% /

Yes coreutils no shows the canonicalized name:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.14-116-g1e18d84

It seems a bit coupled to be searching for "mapper".
Why use that as a selector? Are you backing up devices
rather than files? Is there asnother way to select devices?

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784105: coreutils: df show /dev/dm-0 instead /dev/mapper/XXX

[Pádraig Brady]

On 03/05/15 11:28, Pádraig Brady wrote:
> On 03/05/15 08:16, Rabin Yasharzadehe wrote:
>> Package: coreutils
>> Version: 8.23-4
>> Severity: important
>>
>> Dear Maintainer,
>>
>>> What led up to the situation?
>> After the upgrade to Debian 8 from Debain 7, 
>> the output of the df command have changed.
>>
>> This change broke oue backup scripts which was looking for
>> the mapper string in the df command output.
>>
>>> Old out put format was 
>>
>> # df -Ph /
>> FilesystemSize  Used Avail Use% Mounted on
>> /dev/mapper/vg1-root   14G  3.3G  9.8G  25% /
>>
>>> New (bad) output 
>>
>>  # df -Ph /
>>  Filesystem  Size  Used Avail Use% Mounted on
>>  /dev/dm-0   6.7G  3.6G  2.8G  57% /
> 
> Yes coreutils no shows the canonicalized name:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.14-116-g1e18d84
> 
> It seems a bit coupled to be searching for "mapper".
> Why use that as a selector? Are you backing up devices
> rather than files? Is there asnother way to select devices?

Note if /dev/dm-0 is presented in /proc/mounts
then this is all that is provided by the system to df,
which then has no opportunity to use higher level names.

Padraig


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775197: uniq: -u -d -D options non-orthogonal and confusing when combined

[Pádraig Brady]

On 12/01/15 14:13, Jonathan David Amery wrote:
> Package: coreutils
> Version: 8.13-3.5
> Severity: normal
> 
> I was attempting to use uniq to categorise my data based on the first so
> many characters and I discover that:
> 
> a) it is currently impossible to use uniq to output all lines; with lines 
>   grouped by initial prefix ( -w N ) and separated by an empty line 
>   (--all-repeated=separate) because there is no way to specify outputing
>   all lines
> b) the combination behaviour of -u -d and -D is odd and suboptimal.
> 
> Here is an example with a small example dataset:
> 
> :; cat > uniq-test
> AAA
> AAB
> ABA
> ABC
> ACA
> ADA
> ADD
> ADE
> :; uniq -w 2 -u uniq-test
> ACA
> :; uniq -w 2 -d uniq-test
> AAA
> ABA
> ADA
> :; uniq -w 2 -D uniq-test
> AAA
> AAB
> ABA
> ABC
> ADA
> ADD
> ADE
> :; uniq -w 2 -ud uniq-test
> :; uniq -w 2 -du uniq-test
> :; uniq -w 2 --all-repeated=separate uniq-test
> AAA
> AAB
> 
> ABA
> ABC
> 
> ADA
> ADD
> ADE
> :; uniq -w 2 -u --all-repeated=separate uniq-test
> AAA
> 
> ABA
> 
> ADA
> ADD
> :; uniq -w 2 -c -D uniq-test
> uniq: printing all duplicated lines and repeat counts is meaningless
> Try `uniq --help' for more information.
> :;
> 
>  So in summary:
> 
>  -ud or -du produces no output; but doesn't produce an error (where -c -D 
> does)
> 
>  -u -D produces unexpected output (all the repeated lines except the last one 
>for each set).
> 
>  There is no way to output all lines, with separations.
> 
>  There are a number of ways to address this issue; but I think the best one
> would be to correct behavior and documentation such that:
> 
>  -u outputs any lines which are unique
>  -d outputs the first of any lines which are duplicated
>  -D outputs all lines which are duplicated
>  --all-repeated=METHOD seperates any groups of lines in the specified behavior
> 
>  Such that the output I wanted would be produced with:
> 
> :; uniq -w 2 -u --all-repeated=separate uniq-test
> AAA
> AAB
> 
> ABA
> ABC
> 
> ACA
> 
> ADA
> ADD
> ADE
> :;
> 
>  Thanks,
> 
> J.

Upstream has gone with uniq --group since version 8.22


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781208: coreutils: manpage documents wrong default for --color

[Pádraig Brady]

On 26/03/15 01:44, Christoph Anton Mitterer wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: minor
> 
> 
> Hi.
> 
> ls(1) says:
>> --color[=WHEN]
>> colorize the output; WHEN can be 'never', 'auto', or 'always' (the 
>> default); more info below
> 
> However, the default seems to be never (which is even stated a little
> bit further below in the manpage).

'always' is the default for the --color option, rather than the ls command.
Yes the description is a bit ambiguous, though given the space constraints
in the ls --help output, I can't think of an obvious improvement.

cheers,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#779499: coreutils: split with -d option creates file names that jump from x89 to x9000

[Pádraig Brady]

tag 779499 notabug
close 779499
stop

On 01/03/15 15:08, Beatrice Torracca wrote:
> Package: coreutils
> Version: 8.23-3
> Severity: normal
> 
> Hi!
> 
> I tried using split to divide a text file in chunks using the "-d"
> option to have numeric suffixes. The results I got had the number of the
> suffixes going from 00 to 89 then jumping to 9000 and going on 9001,
> 9002, from there.
> 
> I tried with different prefixes. I don't think the input file has any
> relevance, but just in case i was trying to split the file of the
> translation in Italian of the Debian packages' description that I
> downloaded from here
> 
> http://ftp.de.debian.org/debian/dists/sid/main/i18n/Translation-it.bz2

See the explanation of the -d and -a options at:
http://www.gnu.org/s/coreutils/split

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#779499: coreutils: split with -d option creates file names that jump from x89 to x9000

[Pádraig Brady]

On 02/03/15 17:17, Beatrice Torracca wrote:
> 
>> Messaggio originale
>> Da: p...@draigbrady.com
>> Data: 01/03/2015 21.08
>> A: "Beatrice Torracca", <779...@bugs.debian.org>, 
> "Debian Bug Tracking System"
>> Ogg: Re: Bug#779499: coreutils: split with -d option creates file names that 
> jump from x89 to x9000
> [skip]
> 
>>> I tried using split to divide a text file in chunks using the "-d"
>>> option to have numeric suffixes. The results I got had the number of the
>>> suffixes going from 00 to 89 then jumping to 9000 and going on 9001,
>>> 9002, from there.
>>>
>>> I tried with different prefixes. I don't think the input file has any
>>> relevance, but just in case i was trying to split the file of the
>>> translation in Italian of the Debian packages' description that I
>>> downloaded from here
>>>
>>> http://ftp.de.debian.org/debian/dists/sid/main/i18n/Translation-it.bz2
>>
>> See the explanation of the -d and -a options at:
>> http://www.gnu.org/s/coreutils/split
> 
> Hi!
> 
> I read the explanation of the options you mention. Even with a file as big as 
> to generate only 97 files I get this
> x00
> x01
> ...
> x89
> x9000
> x9001
> 
> x9007
> 
> While it is true that with the option "-a 3" I get the expected results (
> x089, x090, ) I still think it is not the normal behavior to jump from 
> x89 
> to x9000. x90 (and x91...x97) would be a perfectly good name with the same 
> suffix lenght of all the other names (i.e. 2). 

The naming is chosen so that standard shell globbing,
and other simple sorting mechanisms, will result in the desired order.
Consider:

  $ touch x90 x100 && echo x*
  x100 x90

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#779499: coreutils: split with -d option creates file names that jump from x89 to x9000

[Pádraig Brady]

On 02/03/15 20:42, Beatrice Torracca wrote:
> On Monday 02 March 2015, at 17:38 +0000, Pádraig Brady wrote:
>>> I read the explanation of the options you mention. Even with a file as big 
>>> as 
>>> to generate only 97 files I get this
>>> x00
>>> x01
>>> ...
>>> x89
>>> x9000
>>> x9001
>>> 
>>> x9007
>>>
>>> While it is true that with the option "-a 3" I get the expected results 
>>> (
>>> x089, x090, ) I still think it is not the normal behavior to jump from 
>>> x89 
>>> to x9000. x90 (and x91...x97) would be a perfectly good name with the same 
>>> suffix lenght of all the other names (i.e. 2). 
>>
>> The naming is chosen so that standard shell globbing,
>> and other simple sorting mechanisms, will result in the desired order.
>> Consider:
>>
>>   $ touch x90 x100 && echo x*
>>   x100 x90
> 
> I undertand that. I am talking about numbers that are <100 . I get only 98 
> files.
> 
> why not name the last 8: x90 x91x97?
> 
> in your example if I do
>  
> $ touch x89 x90 && echo x*
> x89 x90
> 
> there is no reason why there should not be a x90 file.
> 
> Again I am not talking about a x100 file but of a number of files that is  
> less than 100 but more than 90.
> In particular I have 98 files and I get x00x89, x9000...x9007. why not 
> x90 x91...x97? Those would be ordered correctly with any sorting mechanism.

Between 90 and 99 files is an edge case, and split uses the general method
in this case where it's not aware of how much data is available.

To give split more info you can use the -a or -n options.

Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782981: coreutils: /usr/bin/yes serves no purpose

[Pádraig Brady]

On 20/04/15 02:47, richard jasmin wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: normal
> 
> Dear Maintainer,
> 
> printing 'Y' all over the place or using if 'yes'='yes' serves no purpose from
> any perspective. Thats like saying if true then do something.This is a
> pragmatical programming logical error.Either add NO to the mix and find a
> better use for YES/NO like in dialog package or remove YES from /usr/bin.

'yes' would be better named 'rpt' since it can repeat any parameter to the 
output,
though of course we can't change the naming at this stage.
Please look into things more deeply before further bug reports.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#795270: coreutils: df does not display all nfs mounts for the same mount points

[Pádraig Brady]

On 25/08/15 17:41, Phil Schwartz wrote:
> Re: coreutils 8.21
> 
>  
> 
> These mount points are different as are the targets:
> 
>  
> 
> loui-nac01:/vol/vol_pdbuild /srv/builds nfs defaults,nosuid 0 
>   0
> 
> loui-nac01:/vol/vol_archive /srv/archives   nfs defaults,nosuid 0 
>   0
> 
>  
> 
> Yet the latest df doesn’t show them both:
> 
>  
> 
> df -h
> 
> Filesystem   Size  Used Avail Use% Mounted on
> 
> /dev/mapper/hoth--vg-root117G  2.7G  109G   3% /
> 
> /dev/sda1236M   39M  186M  18% /boot
> 
> loui-nac01:/vol/vol_pdbuild  5.0T  4.3T  740G  86% /srv/builds
> 
>  
> 
> So the logic to get rid of duplicates is too aggressive.  Using “df -a”  the 
> second mount point shows:
> 
>  
> 
> df -ha
> 
> Filesystem   Size  Used Avail Use% Mounted on
> 
> /dev/mapper/hoth--vg-root117G  2.7G  109G   3% /
> 
> /dev/sda1236M   39M  186M  18% /boot
> 
> loui-nac01:/vol/vol_archive  6.5T  5.8T  741G  89% /srv/archives
> 
> loui-nac01:/vol/vol_pdbuild  5.0T  4.3T  741G  86% /srv/builds
> 
>  
> 
> Please fix.  Thanks.
> 

Thanks should be fixed in v8.24

Bug#806947: coreutils: improve expr with huge numbers by GMP

[Pádraig Brady]

On 03/12/15 11:09, Hideki Yamane wrote:
> Package: coreutils
> Severity: minor
> Tags: patch
> 
> Hi,
> 
> Here's a tiny B-D patch to build coreutils with GMP(https://gmplib.org/), 
> it can manage huge numbers with expr.
> 
> * Without GMP 
> 
> $ expr `echo 2 ^ 62 | bc` + 0
> 4611686018427387904
> $ expr `echo 2 ^ 63 | bc` + 0
> expr: 9223372036854775808: Numerical result out of range
> 
> * With GMP (libgmp-dev)
> 
> $ expr `echo 2 ^ 62 | bc` + 0
> 4611686018427387904
> $ expr `echo 2 ^ 63 | bc` + 0
> 9223372036854775808
> 
> Good, no "out of range" :)
> 
> Other distro such as RHEL/CentOS also enabled this and ship it 
> for a long time and I cannot see any hurm for it, and we can get 
> fix from them if there would be.
> 
> Could you consider to apply it in next upload, please?

+1
factor(1) also benefits from GMP:

$ grep GMP src/local.mk
# for various GMP functions
src_expr_LDADD += $(LIB_GMP)
src_factor_LDADD += $(LIB_GMP)

Another thing to consider is depending on openssl
and using ./configure --with-openssl which will
get significantly faster sha*sum implementations.

cheers,
Pádraig

Bug#806947: coreutils: improve expr with huge numbers by GMP

[Pádraig Brady]

On 03/12/15 13:21, Michael Stone wrote:
> On Thu, Dec 03, 2015 at 11:43:59AM +0000, Pádraig Brady wrote:
>> Another thing to consider is depending on openssl
>> and using ./configure --with-openssl which will
>> get significantly faster sha*sum implementations.
> 
> In addition to the concern about making openssl a required component, 
> I'm surprised coreutils uses openssl rather than gnutls, and doesn't 
> have an SSL linking exception in the license.

openssl is where dev of optimized versions of routines is concentrated.
This issue is discussed somewhat at:
http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00021.html
It would be useful to provide a --with-crypto={openssl,gnutls,...} option.

cheers,
Pádraig

Bug#799479: date --iso-8601=m does not use ISO 8601 format as documented

[Pádraig Brady]

On 19/09/15 17:46, Michael Gold wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: minor
> 
> The manual page for 'date' says --iso-8601 will "output date/time in ISO
> 8601 format", but I don't believe the format actually complies with that
> standard when a time is included.
> 
> §4.3.3d says (http://dotat.at/tmp/ISO_8601-2004_E.pdf#):
> "the expression shall either be completely in basic format, in which
> case the minimum number of separators necessary for the required
> expression is used, or completely in extended format, in which case
> additional separators shall be used in accordance with 4.1 and 4.2."
> 
> But --iso-8601=m uses extended format for the date and time, and basic
> format for the timezone.  Since making the option actually use ISO 8601
> format could break scripts, a note in the manual page is probably the
> best fix.  E.g.,
>   "output date/time in ISO 8601 extended format, except for the time
>   zone which will be output in basic format when a time is included and
>   omitted otherwise"
> 
> - Michael

I agree with the above analysis.
I.E. the tz portion should contain a ':' like
  2015-10-23T01:49+01:00

Note date(1) can parse either basic or extended tz:

  $ date --date='2015-10-23T01:49+01:30'
  Fri Oct 23 01:19:00 IST 2015

As can python's iso8601 module for example.

I see the code in date uses %:z (extended format) for --rfc-3339
but %z (basic format) for --iso-8601.  That's because %:z support wasn't
added to gnulib's strftime until 2005, while the --iso-8601 option
was added in 1999.

So there is the possibility of changing the output format
to conform to the standard. How likely is that to break things?
One possibility is that file names might be generated with
`date -Im`, but would even that be likely to break things?

Attached is the change to date(1) to adjust the output format,
and if this is thought too risky, we can instead just
augment the info docs with Michael's comment above.

thanks,
Pádraig.
From f8549660f20a3a394455a6f652ba6d167c1eb3cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Fri, 23 Oct 2015 03:19:18 +0100
Subject: [PATCH] date: use extended format timezone for --iso-8601

* src/date.c (main): Use %:z rather than %z with --iso-8601
as the standard states to consistently use extended format.
Note either format can be parsed by date.
* tests/misc/date.pl: Adjust accordingly.
* doc/coreutils.texi (du invocation): Clarify that "iso"
time styles are only similar to ISO-8601.
(ls invocation): Likewise.
(date invocation): Adjust the comment stating
that only --rfc-3339 output can be parsed by date(1).
* NEWS: Mention the change in behavior.
Reported at http://bugs.debian.org/799479
---
 NEWS   |  3 +++
 doc/coreutils.texi | 28 
 src/date.c |  8 
 tests/misc/date.pl |  8 
 4 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/NEWS b/NEWS
index e771585..4780494 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,9 @@ GNU coreutils NEWS-*- outline -*-
   base64 no longer supports hex or oct --wrap parameters,
   thus better supporting decimals with leading zeros.
 
+  date --iso-8601 now uses +00:00 timezone format rather than +.
+  The standard states to use this "extended" format throughout a timestamp.
+
   df now prefers sources towards the root of a device when
   eliding duplicate bind mounted entries.
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 1b81daa..b1ba097 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7498,8 +7498,8 @@ files; if you want output columns to line up, you may need to insert
 spaces in one of the two formats.
 
 @item full-iso
-List timestamps in full using ISO 8601 date, time, and time zone
-format with nanosecond precision, e.g., @samp{2002-03-30
+List timestamps in full using ISO 8601 like date, time, and time zone
+components with nanosecond precision, e.g., @samp{2002-03-30
 23:45:56.477817180 -0700}.  This style is equivalent to
 @samp{+%Y-%m-%d %H:%M:%S.%N %z}.
 
@@ -7509,14 +7509,14 @@ explain @command{make}'s behavior, since GNU @command{make}
 uses the full timestamp to determine whether a file is out of date.
 
 @item long-iso
-List ISO 8601 date and time in minutes, e.g.,
+List ISO 8601 like date and time in minutes, e.g.,
 @samp{2002-03-30 23:45}.  These timestamps are shorter than
 @samp{full-iso} timestamps, and are usually good enough for everyday
 work.  This style is equivalent to @samp{+%Y-%m-%d %H:%M}.
 
 @item iso
 List ISO 8601 dates for non-recent timestamps (e.g.,
-@samp{2002-03-30@ }), and ISO 8601 month, day, hour, and
+@samp{2002-03-30@ }), and ISO 8601 like month, day, hour, and
 minute for recent timestamps (e.g., @samp{03-30 23:45}).  These
 timestamps are uglier than @samp{long-iso} timestamps, but they carry
 nearly the same information in a smaller space and their brevity helps
@@ -11491,13 +11491,13 @@ with @command{date}, @var{format}'s i

Bug#799479: date --iso-8601=m does not use ISO 8601 format as documented

[Pádraig Brady]

On 23/10/15 03:39, Pádraig Brady wrote:
> On 19/09/15 17:46, Michael Gold wrote:
>> Package: coreutils
>> Version: 8.23-4
>> Severity: minor
>>
>> The manual page for 'date' says --iso-8601 will "output date/time in ISO
>> 8601 format", but I don't believe the format actually complies with that
>> standard when a time is included.
>>
>> §4.3.3d says (http://dotat.at/tmp/ISO_8601-2004_E.pdf#):
>> "the expression shall either be completely in basic format, in which
>> case the minimum number of separators necessary for the required
>> expression is used, or completely in extended format, in which case
>> additional separators shall be used in accordance with 4.1 and 4.2."
>>
>> But --iso-8601=m uses extended format for the date and time, and basic
>> format for the timezone.  Since making the option actually use ISO 8601
>> format could break scripts, a note in the manual page is probably the
>> best fix.  E.g.,
>>   "output date/time in ISO 8601 extended format, except for the time
>>   zone which will be output in basic format when a time is included and
>>   omitted otherwise"
>>
>> - Michael
> 
> I agree with the above analysis.
> I.E. the tz portion should contain a ':' like
>   2015-10-23T01:49+01:00
> 
> Note date(1) can parse either basic or extended tz:
> 
>   $ date --date='2015-10-23T01:49+01:30'
>   Fri Oct 23 01:19:00 IST 2015
> 
> As can python's iso8601 module for example.
> 
> I see the code in date uses %:z (extended format) for --rfc-3339
> but %z (basic format) for --iso-8601.  That's because %:z support wasn't
> added to gnulib's strftime until 2005, while the --iso-8601 option
> was added in 1999.
> 
> So there is the possibility of changing the output format
> to conform to the standard. How likely is that to break things?
> One possibility is that file names might be generated with
> `date -Im`, but would even that be likely to break things?
> 
> Attached is the change to date(1) to adjust the output format,
> and if this is thought too risky, we can instead just
> augment the info docs with Michael's comment above.

Pushed to coreutils upstream at
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-64-g17bbf6c

Bug#803371: coreutils: cp degrades system performance by wasting cache

[Pádraig Brady]

On 29/10/15 10:46, Russell Coker wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: normal
> 
> If you copy many large files to a slow device the amount of memory used for
> cache grows needlessly and impacts overall system performance.  As we already
> have the --reflink option I think that a precedent has been set for adding cp
> options to improve system performance.

Not exactly. That option changes the end state of the copy.

> Firstly I think there should be an option to call fdatasync() after completely
> writing data for a file.  This would reduce the amount of RAM used for write
> back caching to a maximum of the size of one file, in the case where you copy
> many MP4 files to an SD card that would reduce the amount of write back cache
> to something like 300M instead of something large.  dd has a fdatasync option
> to do this.
> 
> Next I think there should be an option to avoid caching file data which would
> be particularly useful when it is known that the size of the files is larger
> than the system RAM (IE caching really can't do any good even if you are
> accessing the files twice).  The O_DIRECT option seems good for this and it's
> an option to dd so it seems that it would work well for cp.

While I agree this is an issue, I'm not sure every too should
get control knobs like that. There are system wide settings
to control the amount of write back cache.  I'm not saying
cp definitely should not get such options, though it warrants
discussion, and that discussion should happen at coreut...@gnu.org.

thanks,
Pádraig

Bug#801654: dircolors: Please support colors on TERM=screen.xterm-256color

[Pádraig Brady]

On 13/10/15 04:11, Josh Triplett wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: normal
> 
> josh@jet:~$ TERM=screen.xterm-256color dircolors
> LS_COLORS='';
> export LS_COLORS

> screen in current unstable seems to set TERM to screen.xterm-256color if
> running in a terminal with TERM=xterm-256color.  (With TERM=xterm,
> screen uses TERM=screen, which dircolors supports.)

It seems screen(1) has multiplied out the various 256 color variants recently:
http://invisible-island.net/ncurses/terminfo.ti.html#tic-screen-256color

I wonder should we add globbing support to TERM entries in dircolors?
I.E. add support for a general entry like:

  TERM *256color*

That would cater for all existing TERMs in Fedora's /etc/DIR_COLORS.256color
for example, and new entries following this common pattern.

Attached is a patch to do that.

From 3491a7702e2d235a255af36e731b84f84da97715 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 13 Oct 2015 12:40:52 +0100
Subject: [PATCH] dircolors: support globbing of TERM entries

* src/dircolors.c (dc_parse_stream): Support globbing of
TERM entries, to allow entries like "TERM *256color*" for example.
* src/dircolors.hin: Reduce the internal list with globbing.
* tests/misc/dircolors.pl: New test cases.
* NEWS: Mention the improvement.
---
 NEWS|  3 +++
 src/dircolors.c |  3 ++-
 src/dircolors.hin   | 39 +--
 tests/misc/dircolors.pl |  8 
 4 files changed, 18 insertions(+), 35 deletions(-)

diff --git a/NEWS b/NEWS
index 9aec259..80f99f3 100644
--- a/NEWS
+++ b/NEWS
@@ -22,6 +22,9 @@ GNU coreutils NEWS-*- outline -*-
 
 ** Improvements
 
+  dircolors now supports globbing of TERM entries in its database.
+  For example "TERM *256color*" is now supported.
+
   du no longer stats all mount points at startup, only doing so
   upon detection of a directory cycle.
   [issue introduced in coreutils-8.20]
diff --git a/src/dircolors.c b/src/dircolors.c
index 3a03f1f..d0bd2e4 100644
--- a/src/dircolors.c
+++ b/src/dircolors.c
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "system.h"
@@ -293,7 +294,7 @@ dc_parse_stream (FILE *fp, const char *filename)
   unrecognized = false;
   if (c_strcasecmp (keywd, "TERM") == 0)
 {
-  if (STREQ (arg, term))
+  if (fnmatch (arg, term, 0) == 0)
 state = ST_TERMSURE;
   else if (state != ST_TERMSURE)
 state = ST_TERMNO;
diff --git a/src/dircolors.hin b/src/dircolors.hin
index 5c89447..f557560 100644
--- a/src/dircolors.hin
+++ b/src/dircolors.hin
@@ -12,16 +12,7 @@
 TERM Eterm
 TERM ansi
 TERM color-xterm
-TERM con132x25
-TERM con132x30
-TERM con132x43
-TERM con132x60
-TERM con80x25
-TERM con80x28
-TERM con80x30
-TERM con80x43
-TERM con80x50
-TERM con80x60
+TERM con[0-9]*x[0-9]*
 TERM cons25
 TERM console
 TERM cygwin
@@ -40,34 +31,14 @@ TERM mach-gnu-color
 TERM mlterm
 TERM putty
 TERM putty-256color
-TERM rxvt
-TERM rxvt-256color
-TERM rxvt-cygwin
-TERM rxvt-cygwin-native
-TERM rxvt-unicode
-TERM rxvt-unicode-256color
-TERM rxvt-unicode256
-TERM screen
-TERM screen-256color
-TERM screen-256color-bce
-TERM screen-bce
-TERM screen-w
-TERM screen.Eterm
-TERM screen.rxvt
-TERM screen.linux
+TERM rxvt*
+TERM screen*
 TERM st
 TERM st-256color
 TERM terminator
-TERM tmux
-TERM tmux-256color
+TERM tmux*
 TERM vt100
-TERM xterm
-TERM xterm-16color
-TERM xterm-256color
-TERM xterm-88color
-TERM xterm-color
-TERM xterm-debian
-TERM xterm-termite
+TERM xterm*
 
 # Below are the color init strings for the basic file types. A color init
 # string consists of one or more of the following numeric codes:
diff --git a/tests/misc/dircolors.pl b/tests/misc/dircolors.pl
index b9f8a1d..2e6f27d 100755
--- a/tests/misc/dircolors.pl
+++ b/tests/misc/dircolors.pl
@@ -33,6 +33,14 @@ my @Tests =
   . "export LS_COLORS\n"}],
  ['other-wr', '-b', {IN => "owt 40;33\n"},
   {OUT => "LS_COLORS='tw=40;33:';\nexport LS_COLORS\n"}],
+ ['term-1', '-b', {IN => "TERM none\nowt 40;33\n"},
+  {OUT => "LS_COLORS='tw=40;33:';\nexport LS_COLORS\n"}],
+ ['term-2', '-b', {IN => "TERM non*\nowt 40;33\n"},
+  {OUT => "LS_COLORS='tw=40;33:';\nexport LS_COLORS\n"}],
+ ['term-3', '-b', {IN => "TERM nomatch\nowt 40;33\n"},
+  {OUT => "LS_COLORS='';\nexport LS_COLORS\n"}],
+ ['term-4', '-b', {IN => "TERM N*match\nowt 40;33\n"},
+  {OUT => "LS_COLORS='';\nexport LS_COLORS\n"}],
 
  # CAREFUL: always specify the -b option, unless explicitly testing
  # for csh syntax output.
-- 
2.5.0

Bug#641166: Please at least mention shuf in sort's man page

[Pádraig Brady]

On 07/10/15 09:43, Philip Hands wrote:
> Hi Micheal,
> 
> A conversation on #debconf-team this morning which mentioned the use of
> sort -R revealed that people that have been bitten by the quirks of
> sort -R have a folkloric understanding that there's something not quite
> right about it compared with what they want, but that even people that
> understand that are not necessarily aware of shuf.
> 
> Since shuf does the thing that people are most often wanting, how about
> just adding a note to the -R option to say something like:
> 
>   you probably want shuf(1) instead

Done upstream at:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-52-ge50f527

> As a data point, I've been aware that GNU commands are documented in
> info for over two decades, but having uselessly invoked info only to be
> looking at a strangely formatted version of the man page again (because
> the real info has been kicked into non-free due to GFDL problems) I
> don't think it would occur to me to consult the info if looking at the
> sort man page.

Note since 8.24, sort man page now points to
http://www.gnu.org/software/coreutils/sort

cheers,
Pádraig.

Bug#804338: coreutils: provide a clean way for optional global cp --reflink=auto

[Pádraig Brady]

On 07/11/15 14:34, Christoph Anton Mitterer wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: wishlist
> 
> 
> Hi.
> 
> It would be nice if the package could provide a clean out-of-the-box
> way to get global --reflink=auto behaviour.
> 
> Starting with 8.24, mv --reflink=auto will be the default, but
> for cp it stays at "never", and probably always will, see Pádraig's
> comment here:
> https://unix.stackexchange.com/questions/80351/why-is-cp-reflink-auto-not-the-default-behaviour/152639#152639
> 
> 
> I have no opinion on whether these arguemnts are good or not,
> some may argue they justify not using reflink per default, some
> may say that people choosing filesystems as btrfs typically expect/want
> their drawbacks/advantages.
> 
> 
> Anyway, it should be easily possible to switch the global default.
> 
> Shell aliases are not a solution, they're typically not expanded in
> non-interactive shells (and while at least bash allows to do so, I'd
> say this is rather dangerous as it potentially breaks countless
> scripts) and as such any system scripts, cron jobs (that make e.g.
> backups) or any other program that directly invokes cp wouldn't benefit
> from it.
> 
> Creating a wrapper shell script and dpkg-diverting the whole story
> doesn't seem proper either, as the wrapper would require additional
> shell execution... and why should people who want the more "native"
> btrfs behaviour have to suffer from such penalty?
> 
> Maybe the coreutils package could provide a 2nd cp binary with
> changed default and people could have things more easily switched,
> either debconf (probably difficult for coreutils ;) ) or some
> proper end-user friendly documentation on how to dpkg-divert.
> 
> 
> Cheers,
> Chris.
> 
> PS: Oh and having 8.24 in Debian would be nice, either
> PS2: I've CCed Pádraig so he may comment if there are any better ways
> to provide solution for this upstream, or even if upstream's view
> may change on the cp/reflink=auto question.

The reason --reflink=auto is not default for cp is because it
changes the end state of the copy. In this case the main issue is
that later changes to the file may give ENOSPC or result in fragmentation.
Now I do agree that you'll get the same issue if you later fill holes
in the file, or change data on deduplicating file systems/devices, ...
So perhaps we should just consider reflink as an implementation option,
and have a higher level --prealloc or whatever for those who care about that.
I.E. instead have cp to do the lightest weight copy possible,
and have --prealloc etc. change that for the edge cases that care
(with the caveat that existing systems may already be depending
 on the current non CoW default behavior).

There is work currently in the kernel for providing vfs_copy_file_range()
which will copy at the lowest level possible. That will do in prefered order;
server copy offload, SCSI COPY, reflink on BTRFS (or XFS etc. when available),
or splice at the VFS level. If cp calls into that by default then
you get your desired behavior by default. I'm looking at that logic
at present, and hope to have it in the next coreutils release,
which would be v9.0 since there are other invasive changes being considered.

cheers,
Pádraig.

Bug#804338: coreutils: provide a clean way for optional global cp --reflink=auto

[Pádraig Brady]

On 07/11/15 19:22, Christoph Anton Mitterer wrote:
> So do you see it coming that this is actually "solved" (meaning refcopy
> works per default out of the box for e.g. btrfs users) upstream ... or
> is it worth to look into making it configurable at the distro level, as
> I proposed above?

I don't see this as something a distro would want to diverge on,
nor something a distro would change in a minor release.
I.E. we should solve this upstream.

cheers,
Pádraig.

Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

[Pádraig Brady]

On 09/08/2014 08:30 PM, Pádraig Brady wrote:
> On 09/08/2014 07:12 PM, Andreas Schwab wrote:
>> Bob Proulx  writes:
>>
>>> For instance, in the touch(1) man page:
>>>
>>>   The full documentation for touch is maintained as a Texinfo manual.  If
>>>   the info and touch programs are properly installed at  your  site,  the
>>>   command
>>>
>>>  info coreutils 'touch invocation'
>>>
>>>   should give you access to the complete manual.
>>>
>>> This is now incorrect (as of 8.23?), because it gives the page:
>>
>> "info touch" still works, which is equivalent to "info '(coreutils)touch
>> invocation'".
>>
>>> Note: Since the coreutils utility doesn't seem to exist in Debian, this
>>> section could be removed, but this problem may reappear in the future.
>>> So, it's better to use the capital letter C.
>>
>> Having info dir entries only differing in case seems like a bad idea.
> 
> I agree.
> 
> We could rename the node, but the bracketed form works well
> without the need for any extra quoting. I.E. this is unambiguous:
> 
>   info '(coreutils) stat invocation'
> 
> The following simple patch implements that.

Another advantage of this more canonical form
is that the pinfo curses info viewer can parse it.

Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

[Pádraig Brady]

On 09/09/2014 01:32 AM, Vincent Lefevre wrote:
> On 2014-09-08 18:10:35 -0600, Bob Proulx wrote:
>> Note that IIRC originally the pointer was:
>>
>>   info touch
>>
>> But that failed due to shortcomings in variously implemented
>> install-info commands that I don't remember now.
> 
> There were actually several (Debian-specific?) problems with this form.
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483554
> 
>> Therefore this was changed to "info -f coreutils touch" IIRC and
>> then later mutated again to "info coreutils 'touch invocation'" to
>> get more canonical.
>>
>> But I think in recent years the install-info problems have been fixed.
> 
> If this is the following bug:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139569
> 
> it was fixed in Debian in September 2009. The simple form now seems
> to be OK.

There is also ambiguity in the shorter form:

  info stat
  info '(coreutils) stat invocation'

Likewise for chmod, chown, kill, link, mkdir, ...

So we'll stick with the longer form
(which is likely to be cut n pasted in any case)

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760861: bug#18428: Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

[Pádraig Brady]

On 09/09/2014 01:51 PM, Michael Stone wrote:
> On Mon, Sep 08, 2014 at 06:10:35PM -0600, Bob Proulx wrote:
>> But I think in recent years the install-info problems have been fixed.
>> Perhaps we don't need to do any of this anymore?  Or perhaps finally
>> getting to the canonical (FILENAME)NODE-WITHIN-FILE form we have
>> finally arrived at the end and should stop there.
> 
> The real solution is to stop pretending that the info documentation is useful.

It's useful to many, but I agree most don't bother with it
due to the awkward non intuitive default info reader _interface_
(though pinfo is a bit better in that regard).

I guess it comes down to people wanting quick notes in the shell
for which they use man, and for longer reading/research they prefer the browser.
As the info _content_ is available for the latter online, this is why I remained
focused in keeping the content up to date and complete.

> We get a lot of bug reports about the man pages & help output, not so many 
> about the info docs. It could be because the info docs are perfect, I suspect 
> it's because they're rarely consulted.

I contend the content is fine and good, though the terminal interface is
generally not used.

> Sometimes we can point to the info doc and close a man page bug with a 
> satisfied sense
> of "they should have read the documentation". But I'm just not sure that 
> documentation
> that seems to exist solely to win a fight over whether behavior is documented 
> is actually helpful.

Agreed.

> Maybe point people at 
> https://www.gnu.org/software/coreutils/manual/html_node/ ?

Personally I use this function:

  cinfo() { xdg-open 
"http://www.gnu.org/software/coreutils/manual/html_node/$1-invocation.html#$1-invocation";;
 }

which I use like `cinfo dd`, though that's another command and not
portable enough currently.

Recently enough we have directed users more to the online info
in the --help output of all commands like:

  GNU coreutils online help: 
  For complete documentation, run: info '(coreutils) ls invocation'

compared to the man page trailer of:
GNU  coreutils  online  help:  
  
  SEE ALSO
The full documentation for ls is maintained as a  Texinfo  manual.   If
the  info and ls programs are properly installed at your site, the command
   info coreutils 'ls invocation'
should give you access to the complete manual.

Though it would be better to have direct links.
Now the above full node URL is too long/awkward, so I've just now setup 
redirects,
so the following proposed new trailers for ls --help and man pages should work:

ls --help:
  ...
  Full documentation online at: 
  Full installed documentation: info '(coreutils) ls invocation'

man ls:
  ...
  SEE ALSO
Full documentation online at: 
Full installed documentation: info '(coreutils) ls invocation'

> Even better would be if it were interactive. E.g., the postgresql project has 
> some really
> nice online docs per-version which allow people to add comments: 
> http://www.postgresql.org/docs/9.3/interactive/index.html

Something to consider for the future.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

[Pádraig Brady]

On 09/08/2014 07:12 PM, Andreas Schwab wrote:
> Bob Proulx  writes:
> 
>> For instance, in the touch(1) man page:
>>
>>   The full documentation for touch is maintained as a Texinfo manual.  If
>>   the info and touch programs are properly installed at  your  site,  the
>>   command
>>
>>  info coreutils 'touch invocation'
>>
>>   should give you access to the complete manual.
>>
>> This is now incorrect (as of 8.23?), because it gives the page:
> 
> "info touch" still works, which is equivalent to "info '(coreutils)touch
> invocation'".
> 
>> Note: Since the coreutils utility doesn't seem to exist in Debian, this
>> section could be removed, but this problem may reappear in the future.
>> So, it's better to use the capital letter C.
> 
> Having info dir entries only differing in case seems like a bad idea.

I agree.

We could rename the node, but the bracketed form works well
without the need for any extra quoting. I.E. this is unambiguous:

  info '(coreutils) stat invocation'

The following simple patch implements that.

thanks,
Pádraig.

diff --git a/src/system.h b/src/system.h
index 162446c..00180cb 100644
--- a/src/system.h
+++ b/src/system.h
@@ -582,7 +582,8 @@ emit_ancillary_info (void)
 last_component (program_name));
 }
   printf (_("For complete documentation, run: "
-"info coreutils '%s invocation'\n"), last_component 
(program_name));
+"info '(coreutils) %s invocation'\n"),
+  last_component (program_name));
 }


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761189: coreutils: wrong 'info' command in ls manpage

[Pádraig Brady]

foremerge 760861 761189
stop

On 09/11/2014 03:03 PM, Antoine Le Gonidec wrote:
> Package: coreutils
> Version: 8.23-2
> Severity: minor
> 
> Dear Maintainer,
> At the end of the ls manpage we have the following instruction :
> 
> SEE ALSO
>The  full documentation for ls is maintained as a Texinfo manual.  If 
> the info and ls programs are properly installed at your site, the command
> 
>   info coreutils 'ls invocation'
> 
>should give you access to the complete manual.
> 
> -
> 
> The command should be :
> info ls
> 
> instead of :
> info coreutils 'ls invocation'
> 
> The latter returns :
> No menu in node `(coreutils.info.gz)coreutils invocation'.

The issue is due to a new "coreutils" info node being present,
and is already handled upstream, though downstream 8.23
could be tweaked to avoid this issue.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737399: metoo

[Pádraig Brady]

On 10/27/2014 05:21 PM, Michael Stone wrote:
> On Mon, Oct 27, 2014 at 11:54:57AM +0000, Pádraig Brady wrote:
>> On 10/27/2014 08:36 AM, Harald Dunkel wrote:
>>> On 10/24/14 18:24, Pádraig Brady wrote:
>>>>
>>>> Note /home doesn't seem to be accessible above
>>>> which is another reason to prefer /data here.
>>>>
>>>
>>> What do you mean by "not accessible"? Both /home and
>>> /data work fine.
>>
>> I was referring to the fact that "-" was shown for the /home entry:
>>
>>  nfs-home:/space/home  -   -  -- /home
>>  nfs-home:/space/data13390666752 10768854016 1941581824  85% /data
> 
> That's df's doing. Potentially something like this would get the suggested 
> behavior:
> 
> --- src/df.c.orig   2014-10-27 12:14:39.633167418 -0400
> +++ src/df.c2014-10-27 13:16:54.524752800 -0400
> @@ -631,6 +631,10 @@
>/* Stat failed - add ME to be able to complain about it later.  */
>buf.st_dev = me->me_dev;
>  }
> +  else if (me->me_remote)
> +{
> +  /* ignore duplicate network mounts */
> +}
>else
>  {
>/* If we've already seen this device...  */

Still not convinced about that hunk.

> @@ -928,7 +932,7 @@
>if (stat (stat_file, &sb) == 0)
>  {
>char const * devname = devname_for_dev (sb.st_dev);
> -  if (devname && ! STREQ (devname, disk))
> +  if (devname && ! STREQ (devname, disk) && !me_remote)
>  {
>fstype = "-";
>fsu.fsu_blocksize = fsu.fsu_blocks = fsu.fsu_bfree =
> 
> 
> The question then being whether making this case work breaks other cases, and 
> whether making it that much harder to explain the logic of what df displays 
> is worth it to avoid explaining why a particular set of mounts is captured by 
> the current logic. :)

I agree that the "-" placeholders above should not have been output.
The attached patch is just a more general version of the hunk above.

thanks!
Pádraig.

>From 19c3646e1fd2964539fbb4240710e2262582c8d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Mon, 27 Oct 2014 23:37:08 +
Subject: [PATCH] df: ensure -a shows all remote file system entries

commit v8.22-125-g9d736f8 printed placeholder "-" values
for device names that didn't match the preferred device name
for a particular mount point.  However that was seen to erroneously
suppress values for aliased host names or exports, common with
remote file systems.

* src/df.c (me_for_dev): Rename from devname_for_dev() so that
we can determine the remoteness as well as the name for the
preferred mount entry.
(get_dev): Don't output place holder values when both
current and preferred mount entries are remote.

Reported in http://bugs.debian.org/737399
---
 src/df.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/src/df.c b/src/df.c
index 5231676..a52afc4 100644
--- a/src/df.c
+++ b/src/df.c
@@ -703,17 +703,17 @@ filter_mount_list (bool devices_only)
 }
 
 /* Search a mount entry list for device id DEV.
-   Return the corresponding device name if found or NULL if not.  */
+   Return the corresponding mount entry if found or NULL if not.  */
 
-static char const * _GL_ATTRIBUTE_PURE
-devname_for_dev (dev_t dev)
+static struct mount_entry const * _GL_ATTRIBUTE_PURE
+me_for_dev (dev_t dev)
 {
   struct devlist *dl = device_list;
 
   while (dl)
 {
   if (dl->dev_num == dev)
-return dl->me->me_devname;
+return dl->me;
   dl = dl->next;
 }
 
@@ -928,12 +928,15 @@ get_dev (char const *disk, char const *mount_point, char const* file,
   else if (process_all && show_all_fs)
 {
   /* Ensure we don't output incorrect stats for over-mounted directories.
- Discard stats when the device name doesn't match.  */
+ Discard stats when the device name doesn't match.  Though don't
+ discard when used and current mount entries are both remote due
+ to the possibility of aliased host names or exports.  */
   struct stat sb;
   if (stat (stat_file, &sb) == 0)
 {
-  char const * devname = devname_for_dev (sb.st_dev);
-  if (devname && ! STREQ (devname, disk))
+  struct mount_entry const * dev_me = me_for_dev (sb.st_dev);
+  if (dev_me && ! STREQ (dev_me->me_devname, disk)
+  && (! dev_me->me_remote || ! me_remote))
 {
   fstype = "-";
   fsu.fsu_blocksize = fsu.fsu_blocks = fsu.fsu_bfree =
-- 
1.7.7.6

Bug#737399: metoo

[Pádraig Brady]

On 10/27/2014 03:12 PM, Harald Dunkel wrote:
> On 10/27/14 12:54, Pádraig Brady wrote:
>>
>> Good point about the man page.
>>
>> I've submitted a patch to mention that -a includes duplicate file systems.
>>
> 
> Thats exactly the point of this bug report: /home and
> /data are not "duplicates". The server has a common
> partition providing both exports, but I doubt that this
> special case should matter on the client.

To the client they're both the same file system (device ID).
(If you fill up one, you fill up the other).

> By "df" showing /data and hiding /home it seems that
> /data is somehow superior to /home.

df uses the path lengths to chose the most appropriate mount point.
In this edge case since the lengths are the same it went
with the last mounted entry as that's the most appropriate one
in some other edge cases.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737399: metoo

[Pádraig Brady]

On 10/28/2014 12:26 PM, Michael Stone wrote:
> On Mon, Oct 27, 2014 at 11:51:44PM +0000, Pádraig Brady wrote:
>>> --- src/df.c.orig   2014-10-27 12:14:39.633167418 -0400
>>> +++ src/df.c2014-10-27 13:16:54.524752800 -0400
>>> @@ -631,6 +631,10 @@
>>>/* Stat failed - add ME to be able to complain about it later.  
>>> */
>>>buf.st_dev = me->me_dev;
>>>  }
>>> +  else if (me->me_remote)
>>> +{
>>> +  /* ignore duplicate network mounts */
>>> +}
>>>else
>>>  {
>>>/* If we've already seen this device...  */
>>
>> Still not convinced about that hunk.
> 
> I'm increasingly coming to the position that this is something that should 
> basically be opaque to the client. The two exports have independent access 
> control policies, and from the user's perspective are two different "things". 
> The admin on the client system treats them as different, and doesn't 
> necessarily have any insight into how the server is configured. Suppressing 
> one as a duplicate is probably more confusing than helpful. And if the server 
> is reconfigured, the you'll suddenly have two entries in df rather than one, 
> even though nothing on the client side has changed. Though it would 
> complicate things even more, maybe a reasonable heuristic would be to 
> suppress remote mounts only if the remote path is a duplicate?

Yes the separate exports argument has merit and detecting those should handle 
this case.
I've attached a proposed patch against upstream

thanks,
Pádraig.

>From b391963bc9e392ced266ef5f91e9c329d460af55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Wed, 29 Oct 2014 02:49:17 +
Subject: [PATCH] df: avoid suppressing remote mounts of separate exports

* src/df.c (filter_mount_list): Separate remote locations may
have different ACLs etc. so list each even if they share
the same remote device and thus storage.
* NEWS: Mention the change in behavior.

Reported in http://bugs.debian.org/737399
Reported in http://bugzilla.redhat.com/920806
---
 NEWS |6 ++
 src/df.c |   33 +
 2 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/NEWS b/NEWS
index 5fbdc6a..6dda9f5 100644
--- a/NEWS
+++ b/NEWS
@@ -30,6 +30,12 @@ GNU coreutils NEWS-*- outline -*-
   dd accepts a new status=progress level to print data transfer statistics
   on stderr approximately every second.
 
+** Changes in behavior
+
+  df no longer suppresses separate exports of the same remote device,
+  as these are probably explicitly mounted and may have separate ACLs etc.
+  [suppression was introduced in coreutils-8.21]
+
 ** Improvements
 
   cp,install,mv will convert smaller runs of NULs in the input to holes,
diff --git a/src/df.c b/src/df.c
index a52afc4..cf0d433 100644
--- a/src/df.c
+++ b/src/df.c
@@ -640,18 +640,27 @@ filter_mount_list (bool devices_only)
 
   if (devlist)
 {
-  /* let "real" devices with '/' in the name win.  */
-  if ((strchr (me->me_devname, '/')
-   && ! strchr (devlist->me->me_devname, '/'))
-  /* let a shorter mountdir win.  */
-  || (strlen (devlist->me->me_mountdir)
-  > strlen (me->me_mountdir))
-  /* let an entry overmounted on a different device win...  */
-  || (! STREQ (devlist->me->me_devname, me->me_devname)
-  /* ... but only when matching an existing mount point, to
-  avoid problematic replacement when given inaccurate mount
-  lists, seen with some chroot environments for example.  */
-  && STREQ (me->me_mountdir, devlist->me->me_mountdir)))
+  if (me->me_remote && devlist->me->me_remote
+  && ! STREQ (devlist->me->me_devname, me->me_devname))
+{
+  /* Don't discard remote entries with different locations,
+ as there may be differing ACLs etc. per remote path, and
+ also these are more likely to be explicitly mounted.  */
+}
+  else if ((strchr (me->me_devname, '/')
+   /* let "real" devices with '/' in the name win.  */
+&& ! strchr (devlist->me->me_devname, '/'))
+   /* let a shorter mountdir win.  */
+   || (strlen (devlist->me->me_mountdir)
+ 

Bug#767932: fslint-gui crashed with IndexError in get_selectable(): list index out of range

[Pádraig Brady]

On 11/03/2014 03:12 PM, Ritesh Raj Sarraf wrote:
> Package: fslint
> Version: 2.44-2
> Severity: normal
> 
> 
> 
> Hi,
> 
> This is a bug that was trapped by apport on Debian. I am not sure how
> reproducible it is, but looking at the backtrace, the bug looks valid.

Fixed upstream with:
http://code.google.com/p/fslint/source/detail?r=291


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#762092: sha...sum man pages refer to nonexistent 'sha...sum invocation' info pages

[Pádraig Brady]

On 09/18/2014 12:54 PM, Rebecca Palmer wrote:
> Package: coreutils
> Version: 8.23-2
> Severity: minor
> Control: tags -1 patch
> 
> The man page of sha512sum states that more documentation can be found at info 
> coreutils 'sha512sum invocation', but this info node does not exist; the 
> correct name is 'sha2 utilities'.  At least sha256sum, and I suspect all four 
> sizes, are also affected.
> 
> (See also #760861.)

Attached 2 patches will address this in the next upstream release.

thanks,
Pádraig.
>From 5c67064016426f7d797c4b686f3bf65d4381e633 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Thu, 18 Sep 2014 14:37:37 +0100
Subject: [PATCH 1/2] doc: ensure the correct texinfo nodes are referenced in
 --help

* src/system.h (emit_ancillary_info): For commands that don't have
a 1:1 mapping with the texinfo node names, provide a mapping to
the correct node.
* doc/coreutils.texi: Add some extra cross references noticed while
checking this.
Fixes http://bugs.debian.org/762092
---
 doc/coreutils.texi |5 -
 src/system.h   |   25 ++---
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index fb083f0..1519fcb 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -4206,7 +4206,8 @@ The commands @command{sha224sum}, @command{sha256sum},
 @command{sha384sum} and @command{sha512sum} compute checksums of
 various lengths (respectively 224, 256, 384 and 512 bits),
 collectively known as the SHA-2 hashes.  The usage and options of
-these commands are precisely the same as for @command{md5sum}.
+these commands are precisely the same as for @command{md5sum}
+and @command{sha1sum}.
 @xref{md5sum invocation}.
 
 Note: The SHA384 and SHA512 digests are considerably slower to
@@ -7961,6 +7962,8 @@ and special characters are represented by backslash escape sequences.
 -b}; that is, by default files are listed in long format and special
 characters are represented by backslash escape sequences.
 
+@xref{ls invocation, @command{ls}}.
+
 @node dircolors invocation
 @section @command{dircolors}: Color setup for @command{ls}
 
diff --git a/src/system.h b/src/system.h
index 1682b32..b5bbec2 100644
--- a/src/system.h
+++ b/src/system.h
@@ -567,7 +567,26 @@ Otherwise, units default to 1024 bytes (or 512 if POSIXLY_CORRECT is set).\n\
 static inline void
 emit_ancillary_info (void)
 {
-  char const * program = last_component (program_name);
+  char const *program = last_component (program_name);
+
+  struct infomap { char const *program; char const *node; } const infomap[] = {
+{ "[", "test invocation" },
+{ "coreutils", "Multi-call invocation" },
+{ "sha224sum", "sha2 utilities" },
+{ "sha256sum", "sha2 utilities" },
+{ "sha384sum", "sha2 utilities" },
+{ "sha512sum", "sha2 utilities" },
+{ NULL, NULL }
+  };
+
+  char const *node = program;
+  struct infomap const *map_prog = infomap;
+
+  while (map_prog->program && ! STREQ (program, map_prog->program))
+map_prog++;
+
+  if (map_prog->node)
+node = map_prog->node;
 
   printf (_("\n%s online help: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
 
@@ -585,8 +604,8 @@ emit_ancillary_info (void)
 }
   printf (_("Full documentation at: <%s%s>\n"),
   PACKAGE_URL, program);
-  printf (_("or available locally via: info '(coreutils) %s invocation'\n"),
-  program);
+  printf (_("or available locally via: info '(coreutils) %s%s'\n"),
+  node, node == program ? " invocation" : "");
 }
 
 static inline void
-- 
1.7.7.6


>From 9d6878c7abaa91fea92d612c7c0a3d699efca106 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Thu, 18 Sep 2014 14:50:47 +0100
Subject: [PATCH 2/2] doc: output correct --help references with
 --program-prefix

* src/system.h (emit_ancillary_info): Take the invariant PROGRAM_NAME
as a parameter, so that consistent references are made to online docs
and texinfo nodes, when a --program-prefix is in place.  Note the
man pages don't need this fix as they're generated before the program
prefix is used.
* NEWS: Mention the improvements in references to online documentation.
---
 NEWS|6 ++
 src/base64.c|2 +-
 src/basename.c  |2 +-
 src/cat.c   |2 +-
 src/chcon.c |2 +-
 src/chgrp.c |2 +-
 src/chmod.c |2 +-
 src/chown.c |2 +-
 src/chroot.c|2 +-
 src/cksum.c |2 +-
 src/comm.c  |2 +-
 src/coreutils.c |2 +-
 src/cp.c|2 +-
 src/csplit.c|2 +-
 src/cut.c   |2 +-
 src/date.c  |2 +-
 src/dd.c|2 +-
 src/df.c|2 +-
 src/dircolors.c |2 +-
 src/dirname.c   |2 +-
 src/du.c|2 +-
 src/echo.c  |2 +-
 src/env.c   |2 +-
 src/expand.c|2 +-
 src/expr.c  |2 +-
 src/factor.c|2 +-
 src/fmt.c   |2 +-
 src/fold.c  |2 +-
 src/getlimits.c |2 +-
 src/groups.c|2 +-
 src/head.c  

Bug#762147: fslint: "Delete" action always hangs and consumes 100% CPU for a long time

[Pádraig Brady]

On 09/18/2014 11:39 PM, David Z wrote:
> Package: fslint
> Version: 2.42-2
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> Ran a duplicate scan of my home dir. It completed normally.
> 
> Selected one particular duplicate file from the list, and clicked the "Delete"
> button. The program immediately became unresponsive for appx. 15-20 seconds on
> a Core i5 notebook 2core cpu. CPU usage shot to 100% for one cpu thread. On a
> single-thread CPU, this would probably hang the entire system for that time.
> 
> This has been the behavior of the "Delete" function in the Debian Wheezy
> version *100%* of the time that I have tried using it, over numerous uses of
> the program, including on different hardware.
> 
> I could just Merge them, but I honestly don't *want* the hardlinks every time.
> 
> 
> 
> -- System Information:
> Debian Release: 7.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable'), (300, 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages fslint depends on:
> ii  findutils  4.4.2-4
> ii  python 2.7.3-4+deb7u1
> ii  python-glade2  2.24.0-3+b1
> ii  python-gtk22.24.0-3+b1
> 
> fslint recommends no packages.
> 
> fslint suggests no packages.
> 
> -- no debconf information
> 
> 

This should be fixed in version 2.44?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737399: metoo

[Pádraig Brady]

On 10/24/2014 03:14 PM, Michael Stone wrote:
> On Fri, Oct 24, 2014 at 03:38:35PM +0200, you wrote:
>> rootfs-   -  -- /
>> /dev/mapper/vg00-root  32896880 4781600   26421176  16% /
> 
>> nfs-home:/space/home  -   -  -- /home
>> nfs-home:/space/data13390666752 10768854016 1941581824  85% /data
> 
> I'm open to suggestions on a useful way to distinguish between these two 
> cases. (Without hard coding a bunch of site-specific rules into df.)

Note /home doesn't seem to be accessible above
which is another reason to prefer /data here.

In general I think df is behaving correctly here,
showing what file system space is available on the system.
If it showed both there would be an ambiguity as to
whether there were two such file systems available.

If you want to see all nfs file systems you can do it explicitly like:

  df -a -t nfs

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737399: metoo

[Pádraig Brady]

On 10/27/2014 08:36 AM, Harald Dunkel wrote:
> On 10/24/14 18:24, Pádraig Brady wrote:
>>
>> Note /home doesn't seem to be accessible above
>> which is another reason to prefer /data here.
>>
> 
> What do you mean by "not accessible"? Both /home and
> /data work fine.

I was referring to the fact that "-" was shown for the /home entry:

  nfs-home:/space/home  -   -  -- /home
  nfs-home:/space/data13390666752 10768854016 1941581824  85% /data

>> In general I think df is behaving correctly here,
>> showing what file system space is available on the system.
>> If it showed both there would be an ambiguity as to
>> whether there were two such file systems available.
>>
>> If you want to see all nfs file systems you can do it explicitly like:
>>
>>   df -a -t nfs
>>
> 
> Sure, unless I am on a "non-coreutils" system, e.g. on AIX:

> Surely I am not asking you to support AIX' df flags. But it
> would be nice if the central tools included in coreutils stay
> in line with other systems.

I don't think we should follow w AIX does
in showing the duplicate file systems.

> BTW, the coreutils man page says about "-a": "include dummy file
> systems". Sorry to say, but this is misleading. "/home" is not
> dummy at all. Its a valid mount point, seperate from others. Esp.
> there is no local partition mounted for "/home", hidden by the
> NFS mount.

Good point about the man page.

I've submitted a patch to mention that -a includes duplicate file systems.

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#813164: coreutils: ls suddenly quotes output

[Pádraig Brady]

On 12/02/16 01:47, Jaroslav Skarvada wrote:
> Hi,
> 
> please revert this ugly change, it's confusing and against GNU coding 
> standards [1]:
> 
>> Likewise, please don’t make the behavior of a command-line program depend
>> on the type of output device it gets as standard output or standard input

ls already changed output depending on if output is a tty
We really don't want to adhere to that guideline for ls.

Bug#813164: coreutils: ls suddenly quotes output

[Pádraig Brady]

On 29/01/16 16:50, Thorsten Glaser wrote:
> Package: coreutils
> Version: 8.25-1
> Severity: minor
> 
> tglase@tglase-nb:~ $ mkdir -p foo/{a,b\ c}; cd foo; /bin/ls   
>   
> a  'b c'
> 
> ’nuff said… this *should* be:
> 
> (pbuild17294)root@tglase-nb:/# mkdir -p foo/{a,b\ c}; cd foo; /bin/ls
> a  b c

A few points about the change.

- It only happens when outputting to terminals
- It disambiguates the output for users
- Output can be pasted back in the shell for further processing
- Users can get back to the old format by adding -N to their ls alias

cheers,
Pádraig

Bug#813164: coreutils: ls suddenly quotes output

[Pádraig Brady]

On 30/01/16 15:45, Christoph Anton Mitterer wrote:
> Hey.
> 
> I've also just stumbled over this... while the idea is nice in
> principle, I think it's quite dangerous as well... even if behaviour is
> preserved when output goes to a terminal.
> 
> a) The quotation alone doesn't necessarily help with copy&paste,
> depending on where you paste.
> 
> b) When the pasted content is actually further to be processed by e.g.
> old scripts (which expect perhaps one *unquoted* name per line) things
> will fail.
> 
> c) We now have what you see is NOT what you get [when stdout is not a
> terminal]
> People do use ls in all it's variations in countless of scripts, and
> they build up their scripts by first trying it out on the terminal to
> see what they get is what they want to have in the script.
> But now, what they get is different in both.
> And the change isn't necessarily one that get's noticed, but it still
> may lead to all kinds of garbage, wrong files being deleted and so on.
> 
> Consider a user writes a script that shall deleted all files from
> 2012... a stupid solution may be something like:
> rm -f "$( ls -1l | grep  | sed 
> "some pattern that removes everything up the filename" | xargs )"
> On the terminal this may give proper:
> rm -f 'file with spaces mythesis.pdf'
> in the script this would give
> rm -f file with spaces mythesis.pdf

ls output really isn't amenable to further processing.
That's what find(1) is focused on.
Though I see what you're saying.

Let's try and force your example into something concrete.
You're saying that people might assume files are always quoted,
but I'm explicitly adding the --quoting option below to
see if users did notice to do that, whether further
processing of ls is valid anyway.

# Very carefully format ls output for processing
ls -ln --quoting=shell-escape --block-size=1 --time-style='+%m' |
# Get rid of the first few space aligned fields while not
# impacting consecutive spaces in a file name.
sed 's/\([^ ]* \)\{4\}//; s/^ *[^ ]* //' |
# Pick files in January
grep ^01 |
# Get the quoted file names
cut -d' ' -f2-
# Process them
xargs ...


Now this mostly works, right up until xargs,
but that will only strip single quotes.
It will not process $'\n' quoting that ls may also output.

Also given the extreme awkwardness in the filtering above,
users are really going to be and should be using find(1) instead.

So yes you have a valid point,
but it's quite a contrived situation.

cheers,
Pádraig.

Bug#813164: coreutils: ls suddenly quotes output

[Pádraig Brady]

On 02/02/16 13:19, Jamie Heilman wrote:
> This behavior needs to be reverted.  There are too many assumptions
> being made, the quoting used is shell-specific, and not universally
> supported.  For example, consider a file who's name contains a tab,
> like "ab".
> 
> $ ls
> 'a'$'\t''b'
> 
> OK, so that syntax is supported by bash and zsh, so if you're using
> one of those shells, maybe you know what it means, and you can cut and
> paste that and make use of it, but in csh or dash, it doesn't mean the
> same thing.

$'...' is in the process of being POSIX standardized.

Even when the shell doesn't support it directly yet,
surely \t is better than ?

Bug#813164: alias ls='ls -N' is not a solution

[Pádraig Brady]

On 03/02/16 06:05, Adam Borowski wrote:
> Also, the proposed workaround, "alias ls='ls -N'" doesn't act reasonably.
> It disables _all_ quoting, including nasty unprintable characters.  When the
> output goes to the terminal, it is meant to be read by a human.  Humans can
> read spaces and apostrophes just fine, they can't read \1 or broken UTF-8.

`ls -N` does revert to the previous behaviour.
I.E. weird chars are replaced with ?

Bug#810539: coreutils: /usr/bin/stat (stat -c "%a" returns "0" instead of "000")

[Pádraig Brady]

On 09/01/16 18:29, lopiuh wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: normal
> 
> Dear Maintainer,
> 
> stat -c "%a" returns "0" instead of "000" in case of getting octal 
> permissions of a directory with permissions 000 (no permissions). No 
> permissions are set in order to prevent users write into unmounted mountpoints
> 
> # ls /mnt/ -lath
> insgesamt 16K
> drwxr-xr-x 1 root root  14 Jan  9 19:12 .
> d- 1 root root   0 Jan  9 19:12 data
> drwxr-xr-x 1 root root 198 Jan  9 19:00 ..
> 
> # stat -c "%a" /mnt/data/
> 0
> 
> Thanks
> 
> lopiuh
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages coreutils depends on:
> ii  libacl1  2.2.52-2
> ii  libattr1 1:2.4.47-2
> ii  libc62.21-6
> ii  libselinux1  2.4-3
> 
> coreutils recommends no packages.
> 
> coreutils suggests no packages.


Control over the precise format of the number is given to the user.
So you can get the behavior you desire like:

$ stat -c %#03a data
000

$ find data -maxdepth 0 -printf %#03m\\n
000

We probably should mention those flags in the upstream docs for %a.
I'll do that now.

thanks,
Pádraig

Bug#816703: regression: "mv from to" now fails when both are the same file

[Pádraig Brady]

On 03/03/16 21:24, Marc Lehmann wrote:

Package: coreutils
Version: 8.25-2
Severity: normal

Dear Maintainer,

as an extension, coreutils supported moving one file to another, when both
refer to the same file.

This support has been lost after upgrading from 8.23-4 (stable) to
8.25-2. That is, in 8.25-2:

# touch a; ln -f a b; mv a b
mv: 'a' and 'b' are the same file

and both names still exist. While in 8.24-4, the "obvious" happens, i.e.
only "b" is left after the mv command.

It would be wonderful if this extension could somehow survive, as the
new behaviour is rather counter-intuitive (one expects that "mv a b", if
possible, makes b refer to a, and a is gone afterwards).

Thanks!

-- System Information:
Debian Release: 8.3
   APT prefers stable
   APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.18-040118-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-2
ii  libattr1 1:2.4.47-2
ii  libc62.21-9
ii  libselinux1  2.4-3

coreutils recommends no packages.

coreutils suggests no packages.


This changed in v8.24 with the NEWS:

  mv no longer supports moving a file to a hardlink, instead issuing an error.
  The implementation was susceptible to races in the presence of multiple mv
  instances, which could result in both hardlinks being deleted.  Also on case
  insensitive file systems like HFS, mv would just remove a hardlinked 'file'
  if called like `mv file File`.  The feature was added in coreutils-5.0.1.

Bug#816703: regression: "mv from to" now fails when both are the same file

[Pádraig Brady]

On 06/03/16 19:46, Marc Lehmann wrote:

On Sun, Mar 06, 2016 at 02:06:47PM -0700, Bob Proulx  wrote:

The kernel system call rename(2) returns 0 for SUCCESS.  And yet the
operation definitely did not succeed.


It did - this is how rename must behave according to POSIX.


I find the above result surprising!


Right, which isn't asurprising :)


So why did this appear to work previously with previous versions of
coreutils mv command?  Because 'mv' didn't previously rename(2) the
files at all.


It worked because I reported this as a bug long ago, and it was changed.

POSIX allows three behaviours for mv in this case:

1. silently succeed
2. issue a disgnostic
3. unlink the source

So very old coreutils used 1, then switched to 3, and now switched to 2,
essentially to please apple users (the race condition could be fixed by a
rename/unlink combination).


place.  The utilities should not hide race condition behavior.


It could be done without races by first renaming the source to a third
name for example, one that doesn't conflict with a concurrent mv (bceause
it can't know that name).

Nevertheless, mv needs to do more than one system call to detect this issue,
so the change doesn't save on system calls.

The only way to save systems calls would be to silently ignore3 this case
(which is allowed by posix).


the script author still wants the racy behavior then the script author
can perform the same actions explicitly and get identical behavior.)


(which script author?)

If you refer to me, this has nothing to do with scripts, it#s simply me
dpoing mv commands sometimes, and expecting mv to do be useful on my
Debian GNU/Linux box, without thinbking too much about apple users and
their problems because their filesystem isn't posix-compliant.


Which means it was historical behavior on multiple kernels originally
and standardized specifically for the reason that changing it would
make portable programs impossible.


Nothing a rename3 or renameat2 (which already exists) couldn't improve with a
flag. In fact, renameat2 with RENAME_EXCHANGE can already be useful. and
renameat2 with RENAME_NOREPLACE can be useful to save on syscalls to detect
this case.


I hope this additional information helps understand what is happening.


I'm not sure anybody was unclear about it. The bug was about keeping
the existing behaviour as a useful extension to POSIX. Unsurprising
mv behaviour would certainly be a useful extension, but upstream
apparently decided to sacrifice quality for better non-posixs (apple)
compatibility. Tough game, but so be it. I'll just keep a copy of mv for
personal use, problem solved.

I do disagree with your mail's implicationh that this is a technical issue,
though - it isn't. It's a policy issue - what weighs more, surprising
behaviour on non-posix filesystems vs. rational behaviour on posix
filesystems, and the decision went to support non-posix filesystems.



It's not to appease case retentive file systems.
There is a race between multiple mv calls issuing unlink();
The race must be fixed in the kernel.
I proposed a new flag to renameat() on the kernel mailing list,
to get the kernel to handle it. When/If that becomes available,
mv can safely restore this behaviour.

Pádraig

Bug#832753: coreutils: stdbuf is not usable for multiarch tools (eg. i386 on amd64)

[Pádraig Brady]

On 28/07/16 15:20, Norbert Lange wrote:
> Package: coreutils
> Version: 8.25-2
> Severity: normal
> 
> Dear Maintainer,
> 
> I am trying to use stdbuf tool on a 32bit Binary, this will result
> in a failure:
> 
> ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/coreutils/libstdbuf.so' from 
> LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
> 
> To make this work seemlessly, 
> LD_PRELOAD would need to be used with the plain library libstdbuf.so
> and the library would need to be installed in the proper locations
> for 64 and 32bit.
> 
> Likely this would mean using a seperate binary package for the library to
> allow co-installing both?

Notes on this upstream at http://bugs.gnu.org/8960

Stuff I noted previously...

You can't install coreutils 32 bit and 64 bit together,
so to support this the libs would need to be separated out to a separate 
package.
I.E. one would have a coreutils package that depended on
coreutils-lib.i686 and coreutils-lib.x86_64, which would
install to /usr/lib{,64}/coreutils/libstbuf.so respectively.
Then you would have the flexibility to set both LD_PRELOAD_{32,64}

Currently we don't support separate (per arch) libs because of:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e23f1795
So we'd have to revert that essentially as automake
is too restrictive here and may support the orig var in newer versions?

We might also have to adjust setting of PKGLIBEXECDIR at build time?

Is this complexity worth it? How often does 64 bit coreutils
need to control buffering for 32 bit programs?
We've not been asked for that flexibility at present.

Bug#851934: bug#23035: date: regression in timezone printing (+%Z)

[Pádraig Brady]

On 17/03/16 17:38, Paul Eggert wrote:
> On 03/16/2016 08:51 PM, Assaf Gordon wrote:
>> I suspect it has something to do with this commit:
>>commit037e3b9847feb46cf6b58d99ce960d3987faaf52
> 
> You're right, and thanks for that detailed bug report. I installed the 
> attached patch, which fixed the bug for me.

This introduced a bug unfortunately due to the side effects of parse_datetime().
parse_datetime resets the TZ env variable but doesn't call tzset().
Hence using the wrong timezone for output.
Previously localtime() called tzset() implicitly.
Perhaps we should call tzset() in parse_datetime() if needed?
I'm not sure as to whether this undoes the fix for bug 23035?

Anyway this avoids the issue on GNU/Linux.

diff --git a/src/date.c b/src/date.c
index ddc702f..1be410c 100644
--- a/src/date.c
+++ b/src/date.c
@@ -578,6 +578,8 @@ show_date (const char *format, struct timespec when, 
timezone_t tz)
 {
   struct tm tm;

+  tzset ();
+
   if (localtime_rz (tz, &when.tv_sec, &tm))
 {
   if (format == rfc_2822_format)

$ TZ="Europe/London" date-before -d 'TZ="Australia/Perth" 2016-08-15 07:00'
Mon Aug 15 07:00:00 AWST 2016

$ TZ="Europe/London" date-after -d 'TZ="Australia/Perth" 2016-08-15 07:00'
Mon Aug 15 00:00:00 BST 2016

p.s. date --debug doesn't have the issue either as it
calls localtime() within parse_datetime()

cheers,
Pádraig

Bug#835904: tail --retry doesn't

[Pádraig Brady]

On 05/09/16 07:07, Harald Dunkel wrote:
> coreutils 8.25-2 seems to have the same problem. Sample:
> 
> 
> % ps -ef | grep tail
> harri 3815  3783  0 Aug30 pts/300:00:00 tail --retry 
> --max-unchanged-stats=5 -f /var/log/messages
> harri11756 11708  0 08:00 pts/400:00:00 grep tail
> 
> % lsof -p 3815
> COMMAND  PID  USER   FD  TYPE DEVICE SIZE/OFFNODE NAME
> tail3815 harri  cwd   DIR8,420480 4456449 /home/harri
> tail3815 harri  rtd   DIR8,3 4096   2 /
> tail3815 harri  txt   REG8,364232   15185 /usr/bin/tail
> tail3815 harri  mem   REG8,3  1697504 1054034 
> /lib/x86_64-linux-gnu/libc-2.23.so
> tail3815 harri  mem   REG8,3   153288 1054030 
> /lib/x86_64-linux-gnu/ld-2.23.so
> tail3815 harri0u  CHR  136,3  0t0   6 /dev/pts/3
> tail3815 harri1u  CHR  136,3  0t0   6 /dev/pts/3
> tail3815 harri2u  CHR  136,3  0t0   6 /dev/pts/3
> tail3815 harri3r  REG8,3   159279  140486 /var/log/messages.1
> tail3815 harri4r  a_inode   0,1104381 inotify
> 
> % ls -alrt /var/log/messages*
> -rw-r- 1 root adm   2057 Aug 15 07:54 /var/log/messages.4.gz
> -rw-r- 1 root adm   1762 Aug 21 08:03 /var/log/messages.3.gz
> -rw-r- 1 root adm  29000 Aug 29 07:53 /var/log/messages.2.gz
> -rw-r- 1 root adm 159279 Sep  4 08:00 /var/log/messages.1
> -rw-r- 1 root adm   2881 Sep  5 07:52 /var/log/messages
> 
> % dpkg -l coreutils
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ NameVersionArchitecture   
> Description
> +++-===-==-==-
> ii  coreutils   8.25-2 amd64  
> GNU core utilities

Oh the file is renamed.
You probably need `tail -F` rather than `tail -f --retry`

Bug#833710: tail -F /var/log/messages missed the rotation

[Pádraig Brady]

On 08/08/16 08:28, Harald Dunkel wrote:
> Package: coreutils
> Version: 8.23-4
> 
> I am running "tail -f --retry /var/log/messages" in a terminal
> for >10 days. Since inotify is available the --max-unchanged-stats
> option is not set, as recommended in the man page.
> 
> Problem: tail ignored the log file rotation last weekend. lsof -p
> shows that it is watching /var/log/messages.1 now:
> 
> % lsof -p 2905
> COMMAND  PIDUSER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
> tail2905 hdunkel  cwdDIR   0,4020480 189573782 /home/hdunkel
> tail2905 hdunkel  rtdDIR  259,0 4096 2 /
> tail2905 hdunkel  txtREG  259,064232657851 /usr/bin/tail
> tail2905 hdunkel  memREG  259,0  1738176   1724334 
> /lib/x86_64-linux-gnu/libc-2.19.so
> tail2905 hdunkel  memREG  259,0   140928   1724331 
> /lib/x86_64-linux-gnu/ld-2.19.so
> tail2905 hdunkel0u   CHR  136,1  0t0 4 /dev/pts/1
> tail2905 hdunkel1u   CHR  136,1  0t0 4 /dev/pts/1
> tail2905 hdunkel2u   CHR  136,1  0t0 4 /dev/pts/1
> tail2905 hdunkel3r   REG  259,0   141711264950 /var/log/messages.1
> tail2905 hdunkel4r     0,110  8294 anon_inode
> 
> Obviously the inotify support did not work for renamed
> files.

There were lots of tail inotify fixes in 8.24
with -f now working with renamed files being explicitly listed

Bug#833932: coreutils: ls -b fails to show Unicode directional characters

[Pádraig Brady]

On 10/08/16 15:21, Peter Ludikovsky wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: normal
> 
> Dear Maintainer,
> 
> This came up due to a posting on debian-user-german [1]. Apparently
> certain Unicode characters, at least LEFT-TO-RIGHT EMBEDDING [2] and
> RIGHT-TO-LEFT EMBEDDING [3] do not trigger the escape code display for
> ls with the -b option.
> 
> An example script is attached, output:
> 
> $ bash unicode_bidir_test.sh 
> + touch LTR
> + touch RTL
> + /bin/ls -l
> total 4
> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 LTR
> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 RTL
> -rw-r--r--. 1 peter peter 148 Aug 10 14:00 unicode_bidir_test.sh
> + /bin/ls -lb
> total 4
> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 LTR
> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 RTL
> -rw-r--r--. 1 peter peter 148 Aug 10 14:00 unicode_bidir_test.sh
> + /bin/ls -lb LTR
> /bin/ls: cannot access LTR: No such file or directory
> + /bin/ls -lb LTR
> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 LTR
> + /bin/ls -lb RTL
> /bin/ls: cannot access RTL: No such file or directory
> + /bin/ls -lb RTL
> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 RTL
> 
> The expected output would be that those characters be shown, as they are
> relevant when accessing a file on the command line.
> 
> [1] https://lists.debian.org/debian-user-german/2016/08/msg00049.html
> [2] http://www.fileformat.info/info/unicode/char/202a/index.htm
> [3] http://www.fileformat.info/info/unicode/char/202b/index.htm
> 
> -- System Information:
> Debian Release: 8.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages coreutils depends on:
> ii  libacl1  2.2.52-2
> ii  libattr1 1:2.4.47-2
> ii  libc62.19-18+deb8u4
> ii  libselinux1  2.3-2
> 
> coreutils recommends no packages.
> 
> coreutils suggests no packages.
> 
> -- no debconf information

Is your locale really "C" ?
With mine set to "C" I get:

$ LANG=C ls -l
-rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ???LTR
-rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ???RTL

$ LANG=C ls -lb
-rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 \342\200\252LTR
-rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 \342\200\253RTL


With the new quoting in version 8.25 you'll get a directly
copy and pasteable representation like:

$ LANG=C ~/git/coreutils/src/ls -l
-rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ''$'\342\200\252''LTR'
-rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ''$'\342\200\253''RTL'


I'll need to experiment a bit with non "C" locale handling,
and with various terminals, to see how best to handle this case.

thanks,
Pádraig

Bug#833932: coreutils: ls -b fails to show Unicode directional characters

[Pádraig Brady]

On 10/08/16 16:15, Peter Ludikovsky wrote:
> 
> 
> Am 10.08.2016 um 16:51 schrieb Pádraig Brady:
>> On 10/08/16 15:21, Peter Ludikovsky wrote:
>>> Package: coreutils
>>> Version: 8.23-4
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>> This came up due to a posting on debian-user-german [1]. Apparently
>>> certain Unicode characters, at least LEFT-TO-RIGHT EMBEDDING [2] and
>>> RIGHT-TO-LEFT EMBEDDING [3] do not trigger the escape code display for
>>> ls with the -b option.
>>>
>>> An example script is attached, output:
>>>
>>> $ bash unicode_bidir_test.sh 
>>> + touch LTR
>>> + touch RTL
>>> + /bin/ls -l
>>> total 4
>>> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 LTR
>>> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 RTL
>>> -rw-r--r--. 1 peter peter 148 Aug 10 14:00 unicode_bidir_test.sh
>>> + /bin/ls -lb
>>> total 4
>>> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 LTR
>>> -rw-r--r--. 1 peter peter   0 Aug 10 14:00 RTL
>>> -rw-r--r--. 1 peter peter 148 Aug 10 14:00 unicode_bidir_test.sh
>>> + /bin/ls -lb LTR
>>> /bin/ls: cannot access LTR: No such file or directory
>>> + /bin/ls -lb LTR
>>> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 LTR
>>> + /bin/ls -lb RTL
>>> /bin/ls: cannot access RTL: No such file or directory
>>> + /bin/ls -lb RTL
>>> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 RTL
>>>
>>> The expected output would be that those characters be shown, as they are
>>> relevant when accessing a file on the command line.
>>>
>>> [1] https://lists.debian.org/debian-user-german/2016/08/msg00049.html
>>> [2] http://www.fileformat.info/info/unicode/char/202a/index.htm
>>> [3] http://www.fileformat.info/info/unicode/char/202b/index.htm
>>>
>>> -- System Information:
>>> Debian Release: 8.5
>>>   APT prefers stable-updates
>>>   APT policy: (500, 'stable-updates'), (500, 'stable')
>>> Architecture: amd64 (x86_64)
>>>
>>> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
>>> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>>
>>> Versions of packages coreutils depends on:
>>> ii  libacl1  2.2.52-2
>>> ii  libattr1 1:2.4.47-2
>>> ii  libc62.19-18+deb8u4
>>> ii  libselinux1  2.3-2
>>>
>>> coreutils recommends no packages.
>>>
>>> coreutils suggests no packages.
>>>
>>> -- no debconf information
>>
>> Is your locale really "C" ?
>> With mine set to "C" I get:
>>
>> $ LANG=C ls -l
>> -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ???LTR
>> -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ???RTL
>>
>> $ LANG=C ls -lb
>> -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 \342\200\252LTR
>> -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 \342\200\253RTL
>>
>>
>> With the new quoting in version 8.25 you'll get a directly
>> copy and pasteable representation like:
>>
>> $ LANG=C ~/git/coreutils/src/ls -l
>> -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ''$'\342\200\252''LTR'
>> -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ''$'\342\200\253''RTL'
>>
>>
>> I'll need to experiment a bit with non "C" locale handling,
>> and with various terminals, to see how best to handle this case.
>>
>> thanks,
>> Pádraig
>>
> 
> Not really, I haven't set any locale on my servers intentionally. Or
> rather, left it at the "POSIX"(?) default during d-i.
> $ localectl status
>System Locale: n/a
> 
>VC Keymap: n/a
>   X11 Layout: de
>X11 Model: pc105
>  X11 Variant: nodeadkeys
> $ cat /etc/default/locale
> #LANG="C"
> $ env | grep LANG
> $ env | grep LC_
> $
> 
> With both LC_ALL=C and LANG=C it shows at least some indication that
> there are other characters. But why not when no explicit locale has been
> set?

Maybe because it's UTF8 based?
I also noticed that in gnome-terminal you can copy/paste the hidden chars
by also selecting the leading space on the file name (though that's certainly 
not obvious).
xterm gives a visual indication of an extra char, and allows selecting it.
So there is an overlap here with terminal handling of the RTL chars

Bug#833948: i18n: stty --help displays bogus block

[Pádraig Brady]

On 10/08/16 19:01, Andrea Stacchiotti wrote:
> Package: coreutils
> Version: 8.25-2
> Severity: minor
> Tags: l10n
> 
> It follows an invocation of stty --help with the italian locale.
> 
> The starting block of the translation file is printed in the middle of the
> output.
> Somehow gettext decided to put in the translation of "", I guess.
> 
> andreas@trelitri:~/Progetti/scanmem/gui$ LANG=it_IT.utf8 stty --help
> Uso: stty [-F DEVICE] | --file=DEVICE] [IMPOSTAZIONE]...
>  or: stty [-F DEVICE] | --file=DEVICE] [-a|--all]
>  or: stty [-F DEVICE] | --file=DEVICE] [-g|--save]
> Print or change terminal characteristics.
> 
> Mandatory arguments to long options are mandatory for short options too.
>   -a, --all  print all current settings in human-readable form
>   -g, --save print all current settings in a stty-readable form
>   -F, --file=DEVICE  open and use the specified DEVICE instead of stdin
>   --help mostra questo aiuto ed esce
>   --version  stampa le informazioni sulla versione ed esce
> 
> Un - opzionale prima di un'IMPOSTAZIONE indica la negazione. Un * indica le
> impostazioni non POSIX. Il sistema sottostante definisce quali impostazioni
> sono disponibili.
> 
> Special characters:
>  * discard CHAR  CHAR will toggle discarding of output
>eof CHAR  CHAR will send an end of file (terminate the input)
>eol CHAR  CHAR will end the line
>  * eol2 CHAR alternate CHAR for ending the line
>erase CHARCHAR will erase the last character typed
>intr CHAR CHAR will send an interrupt signal
>kill CHAR CHAR will erase the current line
>  * lnext CHARCHAR will enter the next character quoted
>quit CHAR CHAR will send a quit signal
>  * rprnt CHARCHAR will redraw the current line
>start CHARCHAR will restart the output after stopping it
>stop CHAR CHAR will stop the output
>susp CHAR CHAR will send a terminal stop signal
>  * swtch CHARCHAR will switch to a different shell layer
>  * werase CHAR   CHAR will erase the last word typed
> 
> Special settings:
>N set the input and output speeds to N bauds
>  * cols Ntell the kernel that the terminal has N columns
>  * columns N same as cols N
>  * [-]drain  wait for transmission before applying settings (on by 
> default)
>ispeed N  set the input speed to N
>  * line Nuse line discipline N
>min N with -icanon, set N characters minimum for a completed read
>ospeed N  set the output speed to N
>  * rows Ntell the kernel that the terminal has N rows
>  * size  print the number of rows and columns according to the kernel
>speed print the terminal speed
>time Nwith -icanon, set read timeout of N tenths of a second
> 
> Control settings:
>[-]clocal disable modem control signals
>[-]cread  allow input to be received
>  * [-]crtsctsenable RTS/CTS handshaking
>csN   set character size to N bits, N in [5..8]
>[-]cstopb use two stop bits per character (one with '-')
>[-]hupsend a hangup signal when the last process closes the tty
>[-]hupcl  same as [-]hup
>[-]parenb generate parity bit in output and expect parity bit in input
>[-]parodd set odd parity (or even parity with '-')
>  * [-]cmspar use "stick" (mark/space) parity
> 
> Input settings:
>[-]brkint breaks cause an interrupt signal
>[-]icrnl  translate carriage return to newline
>[-]ignbrk ignore break characters
>[-]igncr  ignore carriage return
>[-]ignpar ignore characters with parity errors
>  * [-]imaxbelbeep and do not flush a full input buffer on a character
>[-]inlcr  translate newline to carriage return
>[-]inpck  enable input parity checking
>[-]istrip clear high (8th) bit of input characters
>  * [-]iutf8  assume che i caratteri in ingresso siano codificati UTF-8
>  * [-]iuclc  translate uppercase characters to lowercase
>  * [-]ixany  let any character restart output, not only start character
>[-]ixoff  enable sending of start/stop characters
>[-]ixon   enable XON/XOFF flow control
>[-]parmrk mark parity errors (with a 255-0-character sequence)
>[-]tandem same as [-]ixoff
> 
> Output settings:
>  * bsN   backspace delay style, N in [0..1]
>  * crN   carriage return delay style, N in [0..3]
>  * ffN   form feed delay style, N in [0..1]
>  * nlN   newline delay style, N in [0..1]
>  * [-]ocrnl  translate carriage return to newline
>  * [-]ofdel  use delete characters for fill instead of NUL characters
>  * [-]ofill  use fill (padding) characters instead of timing for delays
>  * [-]olcuc  translate lowercase characters to uppercase
>  * [-]onlcr  translate newline to carriage return-newline
>  * [-]onlret newline performs a carriage return
>  * [-]on

Bug#835904: tail --retry doesn't

[Pádraig Brady]

On 29/08/16 08:55, Harald Dunkel wrote:
> Package: coreutils
> Version: 8.23-4
> 
> I am running tail in a dedicated window for some days now:
> 
> % ps -ef | grep tai[l]
> hdunkel   2928  2915  0 Aug15 pts/100:00:00 tail --retry 
> --max-unchanged-stats=5 -f /var/log/messages
> 
> Problem: It's frozen. /var/log/messages is changing all the
> time, but tail doesn't recognize.
> 
> lsof -p shows:
> 
> % lsof -p 2928
> lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
>   Output information may be incomplete.
> COMMAND  PIDUSER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
> tail2928 hdunkel  cwdDIR   0,4020480 189573782 /home/hdunkel 
> (nfs-data:/space/home)
> tail2928 hdunkel  rtdDIR  259,0 4096 2 /
> tail2928 hdunkel  txtREG  259,064232657851 /usr/bin/tail
> tail2928 hdunkel  memREG  259,0  1738176   1724334 
> /lib/x86_64-linux-gnu/libc-2.19.so
> tail2928 hdunkel  memREG  259,0   140928   1724331 
> /lib/x86_64-linux-gnu/ld-2.19.so
> tail2928 hdunkel0u   CHR  136,1  0t0 4 /dev/pts/1
> tail2928 hdunkel1u   CHR  136,1  0t0 4 /dev/pts/1
> tail2928 hdunkel2u   CHR  136,1  0t0 4 /dev/pts/1
> tail2928 hdunkel3r   REG  259,0   100176263640 
> /var/log/messages.1 (deleted)
> tail2928 hdunkel4r     0,110  8294 anon_inode
> 
> 
> AFAICT this is not supposed to happen. According to the man
> page "tail --retry --max-unchanged-stats=5" should reopen
> /var/log/messages.

There were tail fixes in this area in v8.24.
Previously renames may have been missed when inotify was used

Bug#1074776: coreutils: $'\t' and $'\123' escapes are real now

[Pádraig Brady]

On 02/07/2024 21:48, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: minor

Dear Maintainer,

printf(1) says:
   escaping non-printable characters with the proposed POSIX $'' syntax.
this syntax is real as of Issue 8 (POSIX.1-2024).

ls is probably also affected by this since it outputs these.


Fixed upstream with:
https://github.com/coreutils/coreutils/commit/50e85d481

thanks,
Pádraig

Bug#1075768: coreutils: ls doesn't honour COLUMNS if writing to a teletype

[Pádraig Brady]

On 04/07/2024 17:29, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

Quoth POSIX.1-2024:
103406  ENVIRONMENT VARIABLES
103407  The following environment variables shall affect the execution of ls:
103408  COLUMNS  Override the system-selected horizontal display line size, 
used to determine the
103409   column position width for writing multiple text-column output. 
See XBD Chapter
103410   8 (on page 167) for valid values and results when it is unset 
or null. The ls utility
103411   shall use this value to calculate how many pathname text 
columns to write (see
103412   −C). The column width chosen to write the names of files in 
any given directory
103413   shall be constant. Filenames shall not be truncated to fit 
into the multiple text-
103414   column output.

Quoth UNIX™ System V ‒ Release 2.0 User Reference Manual, DEC™ Processors 
(1984):
   There are three major listing formats.  The default format is to list one 
entry
   per line, the -C and -x options enable multi-column formats, and the -m
   option enables stream output format in which files are listed across the 
page,
   separated by commas.  In order to determine output formats for the -C, -x,
   and -m options, /s uses an environment variable, COLUMNS, to determine the
   number of character positions available on one output line.  If this 
variable is
   not set, the terminfo database is used to determine the number of columns,
   based on the environment variable TERM.  If this information cannot be
   obtained, 80 columns are assumed.


Right, both POSIX 2003 and 2008 say that COLUMNS should override any auto width 
determination.
However since the beginning, GNU ls has the -w option to override the width,
and so leaves $COLUMNS as something that is auto set (and usually is by the 
shell).
Since changing this to align with POSIX adds no new functionality,
I'm reluctant to adjust this at this stage, in case COLUMNS is set
incorrectly / inadvertently for some users.
We could safely change this I suppose, gated with the POSIXLY_CORRECT env var.

cheers,
Pádraig.

Bug#1076047: coreutils: timeout: doesn't properly intercept all deadly signals

[Pádraig Brady]

On 09/07/2024 22:21, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

POSIX.1-2024, XCU, timeout, ASYNCHRONOUS EVENTS:
117587  If the signal specified with the −s option, or any signal whose default 
action is to terminate
117588  the process, is delivered to the timeout utility, then unless the 
signal is SIGKILL or
117589  SIGSTOP, the timeout utility shall immediately send the same signal to 
the process or
117590  processes to which it would send a signal when the time limit is 
reached. If the delivered
117591  signal is SIGALRM, timeout may behave as if the time limit had been 
reached instead of
117592  sending SIGALRM.


Right, so POSIX states that timeout(1) should ensure
all termination signals terminate the monitored command.
Currently we only do this for a few terminal centric ones
like SIGINT, SIGQUIT, SIGHUP, ...

cheers,
Pádraig

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

[Pádraig Brady]

On 15/12/2023 15:56, Michael Stone wrote:

I tend to think this was a serious mistake: it breaks the behavior of
existing scripts with no deprecation period. A stated advantage is
better compatibility with freebsd, but I don't understand why that is
more desirable than compatibility with all deployed gnu/linux systems? I
also don't think it's sufficient to try to lawyer out by saying that the
current behavior was undocumented: the previous documentation said that
-n would "silently do nothing" and that the return code would be zero on
success. Logically, unless cp fails to "do nothing", it should exit with
a zero code.

Such a drastic change in behavior demands a new flag, not a radical
repurposing of a widely used existing flag.

I was hoping to see more action on this bug, but that hasn't happened.
I'm not sure I see a way forward for debian other than reverting to the
old behavior. I am reluctant to do so as that will likely lead to
divergent behavior between distributions, but breaking scripts without a
compelling reason is also not good. I would encourage coreutils to
reconsider the change and finding a non-breaking way forward.


Yes it's a fair point.
It's an awkward case, and worth discussing.

To summarise:

  coreutils >= 7.1 had -n skip existing in dest (2009)
  coreutils >= 9.2 has -n immediately fail if existing in dest
  coreutils >= 9.3 has --update=none to skip existing in dest

  FreeBSD >= 4.7/macos has -n immediately fail if existing in dest

  bash has noclobber as a file protection mechanism,
  and fails immediately upon trying to overwrite a file.
  This is more consistent with the new coreutils behavior.

I see a reasonable amount of cp -n usage across github:
https://github.com/search?q=/cp+.*+-n+.*/+path:*.sh&type=code

Now it's not clear which behavior these github usages expect,
and the original docs didn't make it clear which behavior to expect.
A quick scan of the github usages also seem mainly to expect
a protection rather than an update use case, so failing
immediately would be the most appropriate action there too.
Also the original coreutils bug report here expected the new behaviour.

So we probably all agree that failing immediately is the
most appropriate / consistent -n behavior,
but GNU had diverged from that so there are about 10 years
of scripts that may expect the silent skip behavior.

Two options I see are:

- Leave as is and fix -n usages that expected the skip behavior
- Deprecate -n entirely and prompt to use --update={fail,none}

Advantages of leaving as is:
We get consistency of "noclobber" behavior across systems / shells.
We fix cases where previously scripts could have proceeded with
stale old files in place.

Disadvantages of leaving as is:
Users expecting the skip behavior, have to change to --update=none.

There is no potential for data loss etc. so it just comes
down to how disruptive it is, or how often -n was used
with the "skip behavior" assumption.

We've not had much push back as of yet,
and my current thinking is it's not that disruptive a change.
So I'd be 55:45 if favor of keeping things as is.

thanks,
Pádraig.

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

[Pádraig Brady]

On 16/12/2023 21:46, Bernhard Voelker wrote:

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

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

Stlll, Pádraig gave a reasonable summary of why the change was made,


To clarify my summary a little, there I said that -n now _immediately_ fails.
I should have said _silently_ fails.  I.e. the complete copy operation
proceeds as before, and only the exit status is at issue here.


despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.)


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

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

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

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

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


Agreed we should improve the docs a bit for this option.
I'll apply this at least:

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 1f8b356d1..bf0f424d3 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -9057,6 +9057,8 @@ Do not overwrite an existing file; silently fail instead.
 This option overrides a previous
 @option{-i} option.  This option is mutually exclusive with @option{-b} or
 @option{--backup} option.
+See also the @option{--update=none} option which will
+skip existing files but not fail.

 @item -P
 @itemx --no-dereference
diff --git a/src/cp.c b/src/cp.c
index 04a5cbee3..3ccc4c4e6 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -192,8 +192,8 @@ Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.\n\
   -L, --dereferencealways follow symbolic links in SOURCE\n\
 "), stdout);
   fputs (_("\
-  -n, --no-clobber do not overwrite an existing file (overrides 
a\n\
- -u or previous -i option). See also 
--update\n\
+  -n, --no-clobber ensure no existing files overwritten, and 
fail\n\
+ silently instead. See also --update\n\
 "), stdout);
   fputs (_("\
   -P, --no-dereference never follow symbolic links in SOURCE\n\



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


Well RHEL 6 came out a bit after (2010), and had the --no-clobber change,
while RHEL 5 before that did not.

Taking about distros, it's worth noting that the change is Fedora 39
which has been released for a month now.
We'll keep a close eye on issues, but haven't heard much as
of yet at least.


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


Thanks for your thoughts,
appreciated as always.

cheers,
Pádraig

Bug#1059616: "wc -l" gives "illegal instruction"

[Pádraig Brady]

On 29/12/2023 09:52, gates.ocarina...@icloud.com wrote:


Package: coreutils
Version: 9.1-1

When I run command wc -l, it gives “illegal instruction”.
I reinstalled the coreutils package:

$ wc -l

Illegal instruction


$ ls -l | wc -l

Illegal instruction


$ ls -l | wc -lw

       4      29


$ wc test.txt

10  8 18 test.txt


$ cat test.txt | wc -mwl

      10       8      18


$ wc -l test.txt

Illegal instruction


$ cat test.txt | wc -l

Illegal instruction


These upstream patches should address the issue:

https://github.com/coreutils/coreutils/commit/91a74d361.patch
https://github.com/coreutils/coreutils/commit/7814596fa.patch

Bug#628815: coreutils: pinky makes crazy DNS queries

[Pádraig Brady]

On 19/03/2024 10:54, deb...@perkelt.hu wrote:

I looked into this and found that
pinky tries to canonicalize the information in the "Where" column
automaticaly, and it has no option to disable this behaviour.
see line 285 pinky.c:
if (*ut_host)
/* See if we can canonicalize it.  */
host = canon_host (ut_host);
this results in many unnecessary dns queries.
For example on a debian system with acpi-support, /etc/acpi/lid.sh will
make many requests to find the host $WAYLAND_DISPLAY every time the lid
is opened.

"who" has the --lookup (attempt to canonicalize hostnames via DNS)
option, and doesn't do it by default.
Maybe it would be more lightweight to forget about canonicalization
altogether.


pinky is slow here on Fedora 39 too.
I agree that it should avoid this by default.
pinky is supposed to be a lightweight finger after all.

I'll apply the attached to upstream coreutils soon.

thanks,
PádraigFrom 6d0367c00e0998bf5b5a25358c1f1854555cd03e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 19 Mar 2024 13:19:16 +
Subject: [PATCH] pinky: disable location canonicalization by default

Behave like who(1) in requiring --lookup to enable this
often slow feature.  pinky(1) is supposed to be lightweight after all.

* doc/coreutils.texi (who invocation): Adjust the description to no
longer reference dialup, and be more general about the still significant
delays.
(pinky invocation): Reference the same --lookup description.
* src/pinky.c (main): Accept --lookup to enable DNS lookups.
* NEWS: Mention the change in behavior.
Fixes https://bugs.debian.org/628815
---
 NEWS   |  3 +++
 doc/coreutils.texi | 10 +++---
 src/pinky.c| 19 ++-
 3 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 3a7e2aa57..0f4503cbb 100644
--- a/NEWS
+++ b/NEWS
@@ -65,6 +65,9 @@ GNU coreutils NEWS-*- outline -*-
   numfmt will accept lowercase 'k' to indicate Kilo or Kibi units on input,
   and uses lowercase 'k' when outputting such units in '--to=si' mode.
 
+  pinky no longer tries to canonicalize the user's login location by default,
+  rather requiring the new --lookup option to enable this often slow feature.
+
   wc no longer ignores encoding errors when counting words.
   Instead, it treats them as non white space.
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 92c9ceefb..41b644ecf 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -16238,11 +16238,13 @@ Print a line of column headings.
 List only the entries that correspond to processes via which the
 system is waiting for a user to login.  The user name is always @samp{LOGIN}.
 
+@macro lookupOption
 @item --lookup
 @opindex --lookup
-Attempt to canonicalize hostnames found in utmp through a DNS lookup.  This
-is not the default because it can cause significant delays on systems with
-automatic dial-up internet access.
+Attempt to canonicalize hostnames found in utmp through a DNS lookup.
+This is not the default because of potential delays.
+@end macro
+@lookupOption
 
 @item -m
 @opindex -m
@@ -16370,6 +16372,8 @@ format.
 Omit the user's full name, remote host, and idle time when printing in
 short format.
 
+@lookupOption
+
 @end table
 
 @exitstatus
diff --git a/src/pinky.c b/src/pinky.c
index 0843efd55..77c1c2c01 100644
--- a/src/pinky.c
+++ b/src/pinky.c
@@ -61,6 +61,9 @@ static bool include_home_and_shell = true;
 /* if true, use the "short" output format. */
 static bool do_short_format = true;
 
+/* If true, attempt to canonicalize hostnames via a DNS lookup. */
+static bool do_lookup;
+
 /* if true, display the ut_host field. */
 #if HAVE_STRUCT_XTMP_UT_HOST
 static bool include_where = true;
@@ -71,8 +74,15 @@ static bool include_where = true;
 static char const *time_format;
 static int time_format_width;
 
+/* for long options with no corresponding short option, use enum */
+enum
+{
+  LOOKUP_OPTION = CHAR_MAX + 1
+};
+
 static struct option const longopts[] =
 {
+  {"lookup", no_argument, nullptr, LOOKUP_OPTION},
   {GETOPT_HELP_OPTION_DECL},
   {GETOPT_VERSION_OPTION_DECL},
   {nullptr, 0, nullptr, 0}
@@ -279,7 +289,7 @@ print_entry (struct gl_utmp const *utmp_ent)
   if (display)
 *display++ = '\0';
 
-  if (*ut_host)
+  if (*ut_host && do_lookup)
 /* See if we can canonicalize it.  */
 host = canon_host (ut_host);
   if ( ! host)
@@ -499,6 +509,9 @@ usage (int status)
   -i  omit the user's full name and remote host in short format\n\
   -q  omit the user's full name, remote host and idle time\n\
   in short format\n\
+"), stdout);
+  fputs (_("\
+  --lookupattempt to canonicalize hostnames via DNS\n\
 "), stdout);
   fputs (HELP_OPTION_DESCRIPTION, stdout);
   fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -574,6 +587,10 @@ main (int argc, char **argv)
   include_ho

Bug#1072096: PATCH: PR: src/stat.c to add magic for bcachefs filesystem

[Pádraig Brady]

On 28/05/2024 12:50, Paul Hedderly wrote:

Package: coreutils
Version: 9.4-3+b1
Severity: important
Tags: patch upstream d-i

Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***

* What led up to the situation?

stat does not currently  recognise bcachefs
This also means that grub-probe fails to recognise bcachefs

* What was the outcome of this action?

$ sudo stat -f -c %T /
UNKNOWN (0xca451a4e)

* What outcome did you expect instead?

$ sudo ~/apt-src/coreutils-9.4/src/stat -f -c %T /
bcachefs

*** End of the template - remove these template lines ***

Please consider pulling the patch submitted to upstream since this may
take
some time to get accepted (there are many patches waiting on upstream
currently.)

It is a very minor patch that just adds one more magic to the
recognition code.

https://github.com/coreutils/coreutils/commit/6da16c99ff0c6ec35943dd2db5f51c25efb8b508


This is now incorporated in this upstream commit:
https://github.com/coreutils/coreutils/commit/3ce31e6f1

cheers,
Pádraig

Bug#1068864: coreutils: join -a3 errors "invalid field number" even when no field number given

[Pádraig Brady]

On 12/04/2024 14:12, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

$ join -a3 /dev/null /dev/null
join: invalid field number: ‘3’

Not sure where field 3 came from here.


Indeed, that looks to be a copy n paste issue in:
https://github.com/coreutils/coreutils/commit/6f63d53e1

I'll s/field/file/ upstream.

thanks,
Pádraig

Bug#1068889: coreutils: join -t refuses single-character delimiters as "multi-character tab"s

[Pádraig Brady]

On 12/04/2024 23:42, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-1
Severity: normal

Dear Maintainer,

Yes good:
$ cat f1
row1f1  1
urow1   f1  2
$ cat f2
row1f2  1
urow2   f2  2
$ join f? -t '  '
row1f1  1   f2  1

Not good:
$ cat f1
row1ąf1ą1
urow1ąf1ą2
$ cat f2
row1ąf2ą1
urow2ąf2ą2
$ join f? -t 'ą'
join: multi-character tab ‘ą’

Compare manual:
-t CHAR use CHAR as input and output field separator

Compare POSIX.1-202x/D3, XCU, join, OPTIONS:
−t char
Use character char as a separator, for both input and 
output. Every appearance of
char in a line shall be significant. When this option 
is specified, the collating
sequence shall be the same as sort without the −b 
option.


Please try coreutils 9.5 which has improved multi-byte char support in join

Bug#1068892: coreutils: join -t accepts \0 to mean NUL; doesn't document it

[Pádraig Brady]

On 13/04/2024 00:10, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

When trying to decypher -t behaviour for #1068891,
the second empty-string semantic I tried was **(argv + optind),
but that wasn't it. But what /is/ it is -t '\0'; i.e. given
$ cat f1
row1f1  1
urow1   f1  2
$ cat f2
row1f2  1
urow2   f2  2
$ join <(tr '\t' '\0' < f1) <(tr '\t' '\0' < f2) -t '\0' | cat -A
row1^@f1^@1^@f2^@1$
which is great, but the manual doesn't mention this at all.


This is mentioned in the full documentation referenced from the manual

Bug#1068891: coreutils: is join -t '' just comm -12?

[Pádraig Brady]

On 12/04/2024 23:59, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

POSIX.1-202x/D3:
−t char
Use character char as a separator, for both input and 
output. Every appearance of
char in a line shall be significant. When this option 
is specified, the collating
sequence shall be the same as sort without the −b 
option.
so obviously allowing -t '' is an extension.

Manual:
-t CHAR
   use CHAR as input and output field separator

Important: FILE1 and FILE2 must be sorted on the  join  fields.  E.g.,
use  "sort  -k  1b,1"  if 'join' has no options, or use "join -t ''" if
'sort' has no options.  Note, comparisons honor the rules specified by
'LC_COLLATE'.   If  the  input  is  not sorted and some lines cannot be
joined, a warning message will be given.

So given
$ cat f1
row1f1  1
urow1   f1  2
$ cat f2
row1f2  1
urow2   f2  2
which are stable against both sort and sort -k 1b,1
$ join f?
row1 f1 1 f2 1
$ join f? -t '  '
row1f1  1   f2  1
is all as expected.

But
$ join f? -t ''
returns empty. What would empty -t mean, anyway?
The empty string can either be found at every position
(clearly not the case here, otherwise this'd be joined on r and u)
or at no positions, so
$ cat g1
row1
urow1
$ cat g2
row1
urow2
$ join g? -t ''
row1
which is, well
$ comm g? -12
row1

Somehow I don't feel like this is a good recommendation?


Well sort with no options operates on the whole line.
So the corresponding join -t '' operates on the whole line.

cheers,
Pádraig

Bug#1074334: coreutils: what is the undocumented ls --quoting-style=c-maybe mode?

[Pádraig Brady]

On 26/06/2024 19:43, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

$ ls --quoting-style=qwe
ls: invalid argument ‘qwe’ for ‘--quoting-style’
Valid arguments are:
   - ‘literal’
   - ‘shell’
   - ‘shell-always’
   - ‘shell-escape’
   - ‘shell-escape-always’
   - ‘c’
   - ‘c-maybe’
   - ‘escape’
   - ‘locale’
   - ‘clocale’
Try 'ls --help' for more information.

$ man ls | grep c-maybe
$ zgrep c-maybe /usr/share/info/coreutils.info.gz

Best,


Fixed upstream with:
https://github.com/coreutils/coreutils/commit/72588b291

thanks,
Pádraig

Bug#1074334: coreutils: what is the undocumented ls --quoting-style=c-maybe mode?

[Pádraig Brady]

On 28/06/2024 20:48, наб wrote:

On Wed, Jun 26, 2024 at 11:22:07PM +0100, Pádraig Brady wrote:

Fixed upstream with:
https://github.com/coreutils/coreutils/commit/72588b291

This is wrong. Try:
   $ > 'a\a'
   $ ls --quoting-style=c-maybe
   a\a
   $ ls --quoting-style=c
   "a\\a"
obviously a \ needs escaping, as proven by -qc=c escaping it,
so this needs to be listed as an exception.


This is fine I think.
Without quotes the backslash is taken literally,
so there is no ambiguity. I.e. there is "no escaping required".

Taking another example where escaping is _required_:

  $ touch $'a\u' $'a\a'
  $ ls --quoting-style=c-maybe a*
  "a\a"   a\u

The above shows another divergence from strict C escaping,
where \u means universal char escape in C, but is two chars here,
but doesn't _require_ escaping to display,
and so is to be interpreted literally.

cheers,
Pádraig