On 05/02/2016 03:19 PM, Ruediger Meier wrote:
This new quoting style default is just ugly, unreadable and annoying.
If you can think of an unambiguous output style that is beautiful,
readable, and pleasant, please let us know.
ks for reporting the glitch. I installed the attached patch into Gnulib.
From c42727834a8b67caa8d8b7d6b0382170e5ba4d28 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 27 Apr 2016 12:10:54 -0700
Subject: [PATCH] xstrtol: prohibit monstrosities like "1bB&quo
xian andy wrote:
how this happen ?
na001 is configured to assume that gmtime returns leap seconds, and na002 is
not. For example:
$ TZ=America/Los_Angeles date +'%Y-%m-%d %H:%M:%S %z %s';
TZ=zoneinfo-leaps/America/Los_Angeles date +'%Y-%m-%d %H:%M:%S %z %s'
2016-04-19 22:39:29 -0700
Jonny Grant wrote:
Hello
I noticed that cat doesn't have an accurate message in the following use-case:
$ cat missingfile
cat: missingfile: No such file or directory
$ mkdir testdir
$ cat testdir
cat: testdir: Is a directory
The "No such file or directory" message occurs because the
On 04/08/2016 01:51 PM, Ruediger Meier wrote:
On Friday 08 April 2016, Paul Eggert wrote:
For this I suggest the following heuristic. When inferring a format
that would apply to two or more lines of output, try formatting the
first two lines and report an error if they are the same.
Hm, I
On 04/08/2016 05:57 AM, Pádraig Brady wrote:
Do we want to deal with these cases spinning the cpu,
in further patches?
seq 1 nan 1
NaN should be an error in any of the operands.
seq 1 .001 1
For this I suggest the following heuristic. When inferring a format
On 04/04/2016 09:30 AM, Rishabh Dave wrote:
+ char *suffix_from_env;
size_t ssize;
bool simple = true;
+
+ /* If simple_backup_suffix is '~', check environment if we have any there. */
+ if (strcmp(simple_backup_suffix, "~") == 0)
+if ((suffix_from_env =
This is really a question about ssh, not about coreutils, so I suggest
bringing this up in an ssh format. That being said, try debugging your
problem with 'sh -xc' instead of plain 'sh -c'. You'll find that the
problem is not with 'cp'.
On 04/04/2016 08:31 AM, Matthijs Nescio wrote:
Hi,
Indeed, setting the environment variable LC_ALL to C solves the
problem. Thank you. I am a satisfied long-time user of sort so I was
flabbergasted.
Yes, the locale can affect 'sort' in funny ways. Thanks for following
up. Closing the bug
On 04/04/2016 04:12 AM, Kousik Mandal wrote:
[user1@test~]$ ssh user1@testsh -c 'cp -vPprf /tmp/123 /tmp/4576'
ssh -c takes a cipher-spec as an operand, not a command.
On 04/04/2016 04:46 AM, Matthijs Nescio wrote:
I seem to have detected a bug in sort. Can you confirm?
Certainly there is a problem in your 'sort' installation. Perhaps it
depends on the locale? Try setting LC_ALL=C in your environment.
I cannot reproduce the problem with coreutils 8.4 built
On 03/22/2016 09:39 AM, Ruediger Meier wrote:
You could also let true behave like rm if POSIXLY_CORRECT is not set or
if more than zero option given.
This misunderstands the intent of POSIXLY_CORRECT. Setting
POSIXLY_CORRECT does not mean "remove all extensions not specified by
POSIX". It
8d3b0efa6319daa3fb7451582f9fda7db5f3c2e3 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 17 Mar 2016 10:35:18 -0700
Subject: [PATCH] date ls pr: fix time zone abbrs on SysV platforms
The problematic code computed a struct tm in one time zone, and
then printed it or converted it to a
On 03/14/2016 11:02 AM, John Heidemann wrote:
A test case that exhibits locale-specific oddness, with current sort:
... LC_COLLATE=C sort ...
And the happeniess that ensues from control without environment variables:
... sort --locale=C ...
I dunno, these approaches seem about the same to
Paul Vint wrote:
when I type ls in a directory with a couple files with spaces in their
names, since they are enclosed in quotes, those files jump out at me in the
listing
In my experience this is more of a feature than a bug, for many new users.
Here's the old behavior:
$ ls
a b c d
$
On 02/18/2016 08:31 AM, Jason A. Donenfeld wrote:
keep the new
option for nice folks like Eric who have this minority use case.
It's not a minority use case, and this is not simply an issue of cutting
and pasting: it's an issue of having unambigous output. The old behavior
was ambiguous, and
On 02/16/2016 02:29 PM, Assaf Gordon wrote:
Regarding the recent change of default-quoting style,
what do you think about the attached patch,
enabling to set the default style during './configure' ?
We should endeavor to avoid behavior forks like that. Besides, such a
change would violate
On 02/16/2016 10:48 AM, Ruediger Meier wrote:
If the file name _is_ readable at all, then it was printed in a more
readable way.
Sorry, I'm not following. What do you mean by "readable at all"?
Other tools
like less, more, texteditor, webbrowser don't print non-printable
chars. Why ls?
If
On 02/11/2016 08:13 PM, Pádraig Brady wrote:
The changes look good, except for this:
$ seq 1000 | split -n4
$ seq 10 | split -n4
split: -: cannot determine file size: Illegal seek
I.E. it would be better to indicate immediately
if there is an issue determining the file size,
situation. The old
test had a race condition anyway.
I don't know if the failure reflects a bug in coreutils, or in bash, or
in GNU/Hurd elsewhere. If the revised test passes I guess we don't need
to worry about it.
From d839e365717eb95d7358c2f06cfbc34e797592d2 Mon Sep 17 00:00:00 2001
From: P
On 02/10/2016 01:57 PM, Nelson H. F. Beebe wrote:
SKIP: tests/split/line-bytes.sh
Timeout, server 192.168.122.66 not responding.
I presume the test that crashes your system is tests/split/l-chunk.sh,
which invokes commands like 'split -n l/10 /dev/null' and 'split -n 1/2
積丹尼 Dan Jacobson wrote:
Add:
*GNU sleep will pass that floating number to the system, which might or
might not ignore the time indicated after the decimal point.
OR
*GNU sleep will round / truncate? the number into a whole number, before
sending it to the system.
"sleep" has always been
On 01/29/2016 04:38 AM, Lei Wang wrote:
There is one condition can lead to program
overflow, thus argc==2 and argv[1] has only one character, for example
./tail x , will access the next character after x, this maybe a bug
I don't see a bug there. The next character is a null byte, and ISDIGIT
On 01/11/2016 08:56 AM, kenneth.halp...@gmail.com wrote:
For example, if I have the files "foo", "foo1" and "foo bar" in my
directory, a call to
ls foo*
yields only foo and foo1. However, a call to ls "foo "* yields "foo
bar" (sans quotes) as expected.
That's strange, and it's not what I
On 01/11/2016 10:10 AM, kenneth.halp...@gmail.com wrote:
I agree that the shell does seem the most likely culprit.
OK, thanks, I'll mark the bug as "done" for now as far as coreutils is
concerned; we can always unmark it later if it really is an "ls" bug.
Paul Eggert wrote:
Ah. Is this due to glitches when the size grows from (say) "1023 KiB" to "1.0
MiB", or is it something else?
Assuming that's the problem, I installed the attached further patches to try to
fix it. The gnulib update fixes an off-by-one bug I encount
omething else?
>From 9d4e79f5c2d23544f989e73a8b37a3d8908f3b4a Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 31 Dec 2015 11:43:09 -0800
Subject: [PATCH] dd: summarize in --human-readable format too
Problem reported by Linda Walsh in: http://bugs.gnu.org/17505
* NEWS: Document t
Eric Renouf wrote:
If a write to any successfully opened file operand fails
But the write didn't fail here. Instead, a signal was sent to 'tee'. If you
don't want the signal, trap it. E.g.:
trap '' PIPE
for i in {1..300}; do
echo "$i"
echo "$i" >&2
sleep 1
done | tee >(head -1 >
Silvio Ricardo Cordeiro wrote:
If other users have full control over the file (and surrounding directory),
shouldn't they be able to change its date?
Mode 777 does not mean full control; it merely means read, write, and execute
access is granted to everybody. Other users still cannot chmod
This confusion happens often enough that I installed the attached
documentation patch to try to make things clearer.
>From bb1f0a9cd18bc6fa9cf83f23d95929cbab36bfcb Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Mon, 7 Dec 2015 10:03:52 -0800
Subject: [PATCH] doc
How about the attached (untested) patch instead? It should fix the
underlying problem, and thus avoid the need for fiddling with compiler
flags.
diff --git a/configure.ac b/configure.ac
index 66c8cbe..3f546e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -475,7 +475,8 @@ AC_LINK_IFELSE(
{
:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 3 Dec 2015 13:55:44 -0800
Subject: [PATCH] build: port to Studio C on Solaris 12
Reported by Rich Burridge in: http://bugs.gnu.org/22087
* configure.ac (HAVE_UT_HOST, HAVE_C_LINE, stdbuf):
Pacify picky compilers that complain about un
Tim Shaw wrote:
echo big long complicated error message goes here | tee -2
How about "tee /dev/stderr" instead of a new option? "tee /dev/stderr" already
works on many platforms now. We could easily arrange for it to work on the
remaining platforms where it does not already work.
Pádraig Brady wrote:
If a limit, then 0 naturally implies no limit. If a length, then 0 is
meaningless.
It's not meaningless. It means length 0. Length -1 would be meaningless.
That being said, I'm tired of fighting this issue, so please feel free to go
ahead and have 0 mean infinity to the
sha512sum can be faster than sha256sum.
E.g., ‘dd if=/dev/zero bs=1024k count=1024 | time sha256sum’
reports 8.16 user CPU seconds on my host, whereas sha512sum
consumes 5.45 seconds (Fedora x86-64 on an AMD Phenom II X4 910e).
Although sha512sum is still considerably slower on x86, a good
chunk
Benny Halevy wrote:
tail: unrecognized file system type 0x62656570 for ‘/config/subsys/log’. please
report this to bug-coreutils@gnu.org. reverting to polling
How about if we turn off that diagnostic entirely? It's not clear to me that
it's worth the aggravation of getting these bug reports.
Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Sat, 3 Oct 2015 17:01:32 -0700
Subject: [PATCH] tee: simplify argv handling
* src/tee.c (tee_files): Last arg is now char ** instead of char
const **, as that is a bit simpler. All callers changed. Modify
files[-1], not
On 09/22/2015 09:02 PM, Sebastian Unger wrote:
You did get my name ever so slightly wrong in the patch
Oh, sorry! That's embarrassing. Fixed with the attached patch.
>From 617d662865cffa189afdbbcb0e268204091f0eff Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date
you read your own directory that you just created
is likely to run into other problems like this -- i.e., the practice may
introduce more security problems than it closes. But I digress.
From 1f869b77a7e1bb871d58d30edd2ea04a9ac04d32 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.
Thanks for reporting that -- it has been a bug in the manual for sixteen years!
I installed the attached patch.
From d124dbfde656a0aee00d5d89406acdb0c5bfe831 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 17 Sep 2015 00:37:30 -0700
Subject: [PATCH] =?UTF-8?q
Ludovic Courtès wrote:
I think the problem happens when ‘tail’ opens ‘foo’ right in between of
the two notifications: ‘foo’ is still there, and so ‘tail’ doesn’t
report anything.
Does that make sense?
Yes, though if the link count is indeed zero, I'm surprised that 'tail' can open
the file
Pádraig Brady wrote:
+ else if (new_stats.st_nlink == 0) /* XXX: what about multi-linked files. */
That comment was my thought exactly. It appears to be a kernel bug that really
needs to get fixed in the kernel; there just doesn't seem to be a reliable
workaround in user space.
Erik Auerswald wrote:
an explicit Inf keyword is still better than some number that
relies on system limits
With the latest patch, there are no system limits; you can use as big a number
as you like. I'm aware of the use 0 to denote infinity tradition, but I'm
still leery of using a valid
Pádraig Brady wrote:
Also base64 -w0 has similar meaning.
I didn't know that, but I don't like that either. Utilities should use an
explicit representation for infinity, if that's what they need. 'Inf', say.
In the meantime, the patch that I installed is helpful even if we later add an
Linda Walsh wrote:
People with older systems don't always keep upto-date with the latest versions
People that don't keep up-to-date can't rely on any changes that we would make
to 'rm'. Besides, we don't care about SVR4 systems so old that they're no
longer supported.
I ran my little test
On 08/03/2015 12:40 PM, Linda Walsh wrote:
there is no single POSIX --
what version are talking about
The current version, POSIX.1-2013. The code also works in
POSIX.1-2004. At this point older POSIX releases are mostly just
historical curiosities; application developers shouldn't need
Linda Walsh wrote:
find, by itself, has no way to remove all of the items under a
tree even if you own them all.
That's not a problem. Have 'find' call 'rm'. Something like this, say:
find . ! -name . -prune -exec rm -fr {} +
So there's no need to change 'rm'.
Linda Walsh wrote:
Since there is no opposition to this, I presume, all you need now
is a patch?
My impression is that hardly anybody cares about this corner case.
How about the following idea instead? We could have --no-preserve-root also
skip the special treatment for '.' and '..'.
Pádraig Brady wrote:
On 24/07/15 22:46, Assaf Gordon wrote:
If I understand correctly,
The test creates a symlink to a directory then removes execute permissions:
mkdir d
ln -s / d/s
chmod 600 d
Then tries to dereference it:
$ ls -Log d
ls: cannot access d/s:
Assaf Gordon wrote:
it seems that the returned type is always 'directory':
Wow,that's quite a bug. I imagine it affects programs other than 'ls'. Sounds
like it needs to be fixed in the file system or kernel, as it's not realistic to
install workarounds in every application that uses
Assaf Gordon wrote:
$ ./src/ls -Log d
./src/ls: cannot access d/file: Permission denied
./src/ls: cannot access d/chardev: Permission denied
./src/ls: cannot access d/blockdev: Permission denied
./src/ls: cannot access d/s: Permission denied
total 0
?? ? ?? blockdev
0806daf566f36940ec71306b6c519b3038bef9e6 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 23 Jul 2015 18:33:59 -0700
Subject: [PATCH 1/2] build: update gnulib submodule to latest
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnulib b/gnulib
index d03962a..a89e344
Linda Walsh wrote:
I didn't understand the code snippet you sent, but it appears to have rounding
errors. 'sort' doesn't have rounding errors when doing the comparison in
question. Let's not introduce them now.
---
It has to. It's rounding to 2-3 digits.
Sorry, I don't understand that
Pádraig Brady wrote:
done on purpose since v5.90 with:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e3513e1
Yes, the intent was that there be a way from the shell to touch a file even when
one has only its file descriptor. Although POSIX does not specify the behavior
of
Linda Walsh wrote:
since the output
is targetted for 3-4 digits+ a suffix, one would just normalize them.
If the output is that of 'du' or 'df' and has just a few digits and always uses
a consistent suffix, then there is no need to normalize it; that is what 'sort'
does now. In this case
On 07/10/2015 09:29 AM, E. Victor wrote:
The switch -w in the seq command does NOT work
for numbers over 99
Also
seq -w 10 output as 9.9e+008 NOT as 10
I don't observe either problem with coreutils8.24 built for Ubuntu 12.04
x86. For example:
$ src/seq -w 0
On 07/11/2015 03:47 AM, E. Victor wrote:
I got the updated version, and it works perfectly :-)
Thanks for checking; closing the bug report.
Christopher Samuel wrote:
it appears that this ordering is derived purely on
an ordering of the suffixes rather than doing any form of conversion.
It's not purely the suffixes; it looks at suffixes first, and looks at the
numbers if the suffixes are equal.
Looking at both would require
Pádraig Brady wrote:
Nice one!
Yes, very nice.
It looks like the restriction to the k patterns available
was lost with v5.92-1462-g65533e1 and that this should
fix it up.
And thanks for the fix; it looks good to me too.
to test it myself.
I'll CC: this to Andreas Gruenbacher, the author of the recent patches, to give
him a heads-up.
From 9d6bb056bf71db9c377a7da616fe24f0ea393057 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sat, 4 Jul 2015 11:05:00 -0700
Subject: [PATCH] file-has-acl, acl
Sunil Yadav wrote:
dd ibs=20b if=/tmp/test3
output:
16019+1 records in
320380+1 records out
164034561 bytes (164 MB) copied, 4.92556 s, 33.3 MB/s
With coreutil version 8.4 I am facing following error:
dd: writing in Standard stdin: The connection was reset by the
communication partner
Steffen Zahn wrote:
it should be easy to repair
Really? Without significantly affecting performance in the usual case? Let's
see a patch.
Jim Meyering wrote:
same result as before:
OK, let's give up on this approach and try something more direct. I installed
the attached patch; does it work on OS X?
From b1a1450d454698a765a625804fe336305209c696 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Tue, 30 Jun
without --enable-gcc-warnings, as in the attached?
From 99cda43b0f8d5a375a7641eb203e524714947946 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sun, 28 Jun 2015 23:43:35 -0700
Subject: [PATCH] mgetgroups: port to strict OS X
* doc/glibc-functions/getgrouplist.texi (getgrouplist
f805d38258639f45d95b01139e669752651cd1d7 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sun, 28 Jun 2015 23:43:35 -0700
Subject: [PATCH] mgetgroups: port to strict OS X
* doc/glibc-functions/getgrouplist.texi (getgrouplist):
Document the getgrouplist problem.
* lib/mgetgroups.c
this to work I can revert the whole thing.
From 3722df12ad7d5f13dc8bf2cf0ddc329f0541fb86 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Mon, 29 Jun 2015 19:12:07 -0700
Subject: [PATCH] mgetgroups: fix port to strict OS X
* m4/mgetgroups.m4 (gl_MGETGROUPS):
Use more-sensitive -Werror
I installed the attached further patches to gnulib and to coreutils,
respectively. Could you please try:
http://www.cs.ucla.edu/~eggert/coreutils-8.23.212-d8a5.tar.xz
From 4e02fe2fa7eaf841e8f84bf3a370ba4475ebee3c Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Fri, 5 Jun
OK, thanks, I installed the attached patch into gnulib and am marking the bug as
fixed.
From 64910190567221ed14fc0c7c6739b2802aeac613 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sat, 6 Jun 2015 18:20:40 -0700
Subject: [PATCH] acl-permissions: pacify -Wsuggest-attribute
Pádraig Brady wrote:
-man/test.1: src/[$(EXEEXT)
+LBRACKET = [
+man/test.1: src/$(LBRACKET)$(EXEEXT)
I'm afraid that doesn't work, no. For example, with this Makefile:
LBRACKET = [
a: b/$(LBRACKET)
echo a b/$(LBRACKET)
On AIX a plain 'make' will output:
echo a b/[
Michael Felt wrote:
I downloaded, unpacked, ran configure and then make -i. The only thing
notable is still the problem with the man page for 'test' aka '['
(right_bracket)
GEN man/test.1
Yes, somehow AIX make is losing the dependency of man/test.1 on src/[ perhaps
because it treats
Thanks, does the attached (untested) patch fix things for you?
diff --git a/lib/acl-internal.h b/lib/acl-internal.h
index 11fdea1..d592a75 100644
--- a/lib/acl-internal.h
+++ b/lib/acl-internal.h
@@ -289,6 +289,10 @@ struct permission_context {
int get_permissions (const char *, int, mode_t,
Michael Felt wrote:
root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
rm -f src/coreutils.h
for prog in ; do prog=`basenam
Yes, it looks like something went wrong in your build process and you're using a
Makefile.in generated from unpatched sources. I just
Michael Felt wrote:
GEN src/coreutils.h
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.
This looks like the coreutils patch wasn't properly propagated somehow. What's
the output of 'make V=1'?
100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2015-06-05 Paul Eggert egg...@cs.ucla.edu
+
+ acl-permissions: port to older AIX, C89 HP-UX
+ * lib/get-permissions.c (get_permissions):
+ If USE_ACL HAVE_GETACL /* HP-UX */, don't assume C99.
+ If USE_ACL HAVE_STATACL /* older AIX */, add
Eric Blake wrote:
Actually, POSIX_does_ allow for missing words between 'in' and the
terminator (; or newline) before 'do' (whether by a word that expands to
nothing, or by omission of words), requiring that the body of the for
statement is skipped in that case:
Ah, sorry, I was thinking of
it a try.
From f6dc56f4754838069037a2e03553e8badc065c05 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 4 Jun 2015 12:15:35 -0700
Subject: [PATCH] build: port single_binary_prog to POSIX shell
Problem reported privately by Michael Felt.
* Makefile.am (install-exec-hook
I found one nit:
+AC_CHECK_HEADERS([linux/xattr.h])
+AC_CHECK_HEADERS([sys/xattr.h],
+ [AC_CHECK_FUNCS_ONCE([getxattr])])
This is missing _ONCE and non-ONCE calls, which doesn't work as
expected. Simplest fix is to replace AC_CHECK_FUNCS_ONCE with
AC_CHECK_FUNCS.
On 05/26/2015 01:53 PM, Andreas Gruenbacher wrote:
---
lib/acl-internal.c| 30 ++
This one is missing a patch to ChangeLog. Please put the commit message
into the ChangeLog. Also, please put the string Bug#20666 somewhere
into the commit message body and the ChangeLog (they should
On 05/27/2015 02:41 PM, L. A. Walsh wrote:
*** file = libvtkUtilitiesPythonInitializer-pv4.2.so.1
grep: invalid UTF-8 byte sequence in input
This looks like you're using an old version of libpcre, or of grep. I
can't reproduce the problem with the latest stable versions of both
(libpcre
Toralf Förster wrote:
I do bind-mount a directory from the host (~35 GB of downloaded package files)
onto a directory of each of the chroots to save space and bandwith.
A du -ms however counts that value just for the first listed directories
It sounds like 'du' is doing the right thing. du
Jim Meyering wrote:
+ return err == EOPNOTSUPP
+#if ENOTSUP != EOPNOTSUPP
+|| err == ENOTSUP
+#endif
+;
Would the following work instead? It's a bit cleaner to avoid #if:
return err == EOPNOTSUPP || (ENOTSUP != EOPNOTSUPP err == ENOTSUP);
Bernhard Voelker wrote:
Could we work around
it?
Sure, how about if we shrink it down to 0.19? Would that work for you?
I picked 0.19.4 only because the old value was too low for gnulib and I was at
0.19.4. I think it needs to be at least 0.19, because of the recent gnulib changes.
Pádraig Brady wrote:
Further reductions in deps
might be possible by splitting up libselinux, allowing apps like ls
that just read contexts, to link with the appropriate lib.
I tried to see how to send a copy of this bug http://bugs.gnu.org/20437 to the
libselinux developers, but the
Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sun, 26 Apr 2015 15:46:18 -0700
Subject: [PATCH 1/2] build: update gnulib submodule to latest
* bootstrap.conf (gnulib_modules): Add file-has-acl.
(buildreq): Bump autopoint and gettext to 0.19.4.
* configure.ac
On 04/09/2015 11:20 AM, Andreas Grünbacher wrote:
Sounds like the Savannah server should be be checking that for all
its projects that use gnulib.
No, because some projects deliberately don't want this check. Emacs is
one (gnulib imports are copied into the Emacs repository), Tar is
another
Andreas Grünbacher wrote:
This behavior is discouraging testing; I find that quite annoying.
Me too. It's bitten me several times and I can never remember how to shut it
off. Perhaps we should remove that test from 'make check' and have a further
rule 'make checker' that is stronger than
L. A. Walsh wrote:
I was wondering if the changes to 'mv' might also have fixed this
(10468/10471) bug.
Haven't a clue. Why don't you try the bleeding-edge version of coreutils and
see? Presumably you have the oddball file system in question available, and can
easily try it out. (I don't
I could be talked into that, particularly given Matlab's misbehavior
here. Jim?
From 666dec6b34e1204b173672f9bad47f34cd8bad3f Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Fri, 27 Mar 2015 15:01:35 -0700
Subject: [PATCH] nohup: clarify stdin redirection
Problem reported
On 03/17/2015 02:23 PM, Robson Júnior wrote:
`test -e` with no filename being passed to. It returns 0, although it
should be 1.
No, 'test -e' should exit with status 0, because '-e' is a nonempty
string. In general, 'test X' exits with status 0 if and only if X is
nonempty. POSIX requires
Update of bug #19546 (project coreutils):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #4:
This was fixed as
Pádraig Brady wrote:
We would probably change them all if this was thought to be a problem.
I don't think it's a real problem. I've never run into a system where a
nonrecursive function can't declare a local variable of size BUFSIZ, and given
the long tradition of software doing just that I
On 02/23/2015 01:28 PM, Ludovic Courtès wrote:
I suspect this isn’t needed.
This is needed so that 'ls -l' can output a date format suitable for the
current locale. These formats aren't part of glibc and so are not in
glibc's LC_TIME information. The default formats for the C locale are
If I understand correctly, it doesn't appear that this is a bug that coreutils
can fix, as POSIX implies (and many programs expect) that formats like %d and %B
and %Y act independently of context.
If it's any consolation, the default output of 'date' in the C locale:
Thu Jun 28 15:10:00 PDT
matshyeq wrote:
I think I've found an issue when head is called with -n-0 parameter
It should return whole file but only seem to work for files with newline
character at the end.
I'm not observing this problem on Ubuntu 14.10 x86-64; see below. Which
platform and version of 'head' are you
catch the bug.
From a7422034e94671831bcdd170dbb1dc4348c536a5 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sat, 7 Feb 2015 15:15:31 -0800
Subject: [PATCH] full-read: fix license notice typo
* lib/full-read.h: Remove a stray line in the license notice.
Reported by Sam Ellis
If we're adding this sort of option, shouldn't we also give users the ability to
invoke fsync and fdatasync on a single file, as opposed to syncfs on an entire
file system?
Giuseppe Scrivano wrote:
Should we instead add something like --file-system and
--data-only, respectively for syncfs and fdatasync and use fsync if no
option is specified?
Yes, thanks, that sounds reasonable. I suggest --data rather than --data-only,
as fdatasync is allowed to synchronize
Thanks for reporting that. I installed the attached patch, which has a test for
the bug.
From bb3b32b2d0a488fbaa146de062aafc762f974577 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Mon, 5 Jan 2015 19:40:03 -0800
Subject: [PATCH] shuf: do not mishandle 'shuf -i0-0 1
On 12/16/2014 05:46 AM, Pádraig Brady wrote:
if (xstrtoul (optarg, NULL, 10, val, ) != LONGINT_OK
-|| MIN (INT_MAX, SIZE_MAX) val)
- error (EXIT_FAILURE, 0, _(%s: invalid number), optarg);
+|| (MIN (INT_MAX, SIZE_MAX) val (errno = EOVERFLOW)))
+
KO Myung-Hun wrote:
/* Redirection and wildcarding when done by the utility itself.
Generally a noop, but used in particular for native VMS. */
#ifndef initialize_main
-# define initialize_main(ac, av)
+# ifndef __OS2__
+# define initialize_main(ac, av)
+# else
What happened to VMS?
901 - 1000 of 3456 matches
Mail list logo
