On 11/05/2024 10:14, Dan Jacobson wrote:
join should have an option to return an error value in the shell's $?
if any lines are not matched.
Currently the man page doesn't even mention a return value. So it is not
set in stone yet.
Currently one must save -v output in a file then use test -s
join should have an option to return an error value in the shell's $?
if any lines are not matched.
Currently the man page doesn't even mention a return value. So it is not
set in stone yet.
Currently one must save -v output in a file then use test -s do detect
if there were any non-matched
On 02/05/2024 07:16, Nineteendo INC wrote:
coreutils version: stable 9.5 (bottled)
OS version: macOS 13.6.6 (22G630)
`realpath` doesn’t behave correctly for unreadable symlinks:
wannes@Stefans-iMac ~ % ln -s . src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users
wannes@Stefans-iMac ~ % chmod
coreutils version: stable 9.5 (bottled)
OS version: macOS 13.6.6 (22G630)
`realpath` doesn’t behave correctly for unreadable symlinks:
wannes@Stefans-iMac ~ % ln -s . src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users
wannes@Stefans-iMac ~ % chmod -h 000 src
wannes@Stefans-iMac ~ %
tag 68866 notabug
close 68866
stop
On 2/1/24 04:09, Seungchul Lee wrote:
man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.
'man pwd' and 'env pwd --help' also tells:
NOTE: your
Hello,
man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.
Sincerely yours,
Lee.
tag 68064 notabug
close 68064
stop
On 27/12/2023 17:29, Larry Ploetz wrote:
It seems like there might be a problem with date addition when the base
date is specified as “day Monthname” instead of “Monthname day”, where
the offset is being interpreted as an absolute year value. This may be
It seems like there might be a problem with date addition when the base
date is specified as “day Monthname” instead of “Monthname day”, where
the offset is being interpreted as an absolute year value. This may be
locale-specific.
:bin larry$ locale
LANG="en_US.UTF-8"
On 14/08/2023 20:02, Bruno Haible wrote:
Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:
CC src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this
function); did you
Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:
CC src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this
function); did you mean 'MACH_PORT_NULL'?
984 | if (file
Just creating a bug to track the recent fixes
to read error handling in various coreutils. I.e.:
https://github.com/coreutils/coreutils/commit/9d333aca4 cksum
https://github.com/coreutils/coreutils/commit/0e62ba282 tsort
https://github.com/coreutils/coreutils/commit/5595673d5 numfmt
https
.
cheers,
Pádraig
From a9bd274616a8d2e99736b498e657cda4e6954f3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Tue, 28 Mar 2023 14:24:29 +0100
Subject: [PATCH] dircolors: diagnose read errors
* NEWS: Mention the fix.
* src/dircolors.c: Fail upon read error from getline
On 28/03/2023 09:54, Paul Eggert wrote:
Thanks for reporting that. I installed the attached to fix it.
Looks good thanks.
Also worth the attached test and NEWS,
which I've pushed.
cheers,
PádraigFrom a4525de1ef593cb3873eb88caa7279eb32669bda Mon Sep 17 00:00:00 2001
From:
= getline (, , in_stream);
if (line_length < 0)
{
- /* FIXME: detect/handle error here. */
+ if (ferror (in_stream))
+die (EXIT_FAILURE, errno, _("%s: read error"),
+ quotef (input_filename));
break;
}
--
2.37.2
Hello
The usual case is:
$ echo "2023-03-27 08:30:00" > dates.txt
$ echo "2023-04-01 12:00:00" >> dates.txt
$ /usr/bin/date -f dates.txt
Mon Mar 27 08:30:00 CEST 2023
Sat Apr 1 12:00:00 CEST 2023
If done on a non existing file, we get:
$ date -f non-existing
/usr/bin/date: non-existing: No
On 22/02/2023 13:28, Martin Castillo wrote:
Hi,
the info page of cp says
Plain ‘--reflink’ is equivalent to ‘--reflink=when’.
but probably means
Plain ‘--reflink’ is equivalent to ‘--reflink=always’.
Martin Castillo
Already fixed in
Hi,
the info page of cp says
Plain ‘--reflink’ is equivalent to ‘--reflink=when’.
but probably means
Plain ‘--reflink’ is equivalent to ‘--reflink=always’.
Martin Castillo
$ sort --human-numeric-sort -nr
sort: options '-hn' are incompatible
Say instead:
sort: options --human-numeric-sort (-h), and --numeric-sort (-n), are
incompatible.
Else some projects might be delayed by days, as some people need to
email other people to ask...
"Can't blame me. That's not
tag 60030 notabug
close 60030
stop
On 13/12/2022 02:50, Malin Freeborn wrote:
Hi bug-team,
There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:
%F full date; like %+4Y-%m-%d
The example shows the `%` sign before
Hi bug-team,
There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:
%F full date; like %+4Y-%m-%d
The example shows the `%` sign before the `+`.
Best,
- Malin
tag 59901 notabug
close 59901
stop
On 08/12/2022 03:44, Ridwan Shariffdeen wrote:
Hi,
Running valgrind on src/split with the following command reports a memory
error. I have attached the valgrind output (i.e. Use of uninitialised value)
I couldn't repro this here, and
`src/split` above
On 10/17/22 07:44, Ruslan Kovtun wrote:
According to "do one thing and do it well" and to the fact of '-d/--date'
option existence, `date` should be able to parse its default output in any
locale.
Patches would be welcome. Good luck getting it to work, though. Many
date formats are ambiguous,
$ date -d "$( date )"
date: invalid date ‘Пн 17 окт 2022 17:34:00 EEST’
$ date -d "Mon 17 oct 2022 17:34:00 EEST"
Пн 17 окт 2022 17:34:00 EEST
According to "do one thing and do it well" and to the fact of '-d/--date'
option existence, `date` should be able to parse its default output in any
On 9/25/22 07:25, Pádraig Brady wrote:
How about the attached to add a NEWS entry,
and add DS_EMPTY, DS_NONEMPTY enums to make the code easier to read?
Sure, that looks good; thanks.
Oh, I forgot that via code inspection I found a theoretical portability
bug in fts while I was looking into
On 25/09/2022 00:37, Paul Eggert wrote:
I ran into this problem when attempting to recursively
remove a directory in a filesystem on flaky hardware.
Although the underlying readdir syscall failed with errno == EIO,
rm issued no diagnostic about the I/O error.
This looks good.
How about
I ran into this problem when attempting to recursively
remove a directory in a filesystem on flaky hardware.
Although the underlying readdir syscall failed with errno == EIO,
rm issued no diagnostic about the I/O error.
Without this patch I see this behavior:
$ rm -fr baddir
rm: cannot
Thanks! That solved the issue!
On Tue, Sep 6, 2022 at 3:18 PM Paul Eggert wrote:
> Thanks for the bug report. Please try this Gnulib patch, which should
> appear in the next Coreutils release:
>
>
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
Thanks for the bug report. Please try this Gnulib patch, which should
appear in the next Coreutils release:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
this with the same
arguments on x86_64 and armv7l with glibc 2.27.
Configure line is:
./configure --prefix=/usr/local --libdir=/usr/local/lib
--mandir=/usr/local/share/man --build=i686-cros-linux-gnu
--host=i686-cros-linux-gnu --target=i686-cros-linux-gnu --program-prefix=''
--program-suffix=''"
The
_now = false;
if (x->interactive != I_ALWAYS_NO
- && ! same_file_ok (src_name, _sb, dst_dirfd, dst_relname,
+ && ! same_file_ok (src_name, _sb, dst_dirfd, drelname,
_sb, x, _now))
{
err
and return ENOENT.
Instead, the exact same steps work on arch linux 2022.03, which has
coreutils 9.0-2. Note that -x should prevent trying to copy /mnt under
itself; on 2022.03, there is a proper error message for cp -a / /mnt
without -x.
On 4/28/21 16:23, Mark Krenz wrote:
So I'm not sure if this is a problem with coreutils or a change in the
zoneinfo database. Any ideas?
This appears to be a problem in the GNU C library, when its mktime
deciphers the relatively unusual time zone history of Indiana.
I installed the attached
tag 53674 notabug
close 53674
stop
On 2/1/22 03:38, Alexandre Louisdhon wrote:
> Error- tail: unrecognized file system type 0x794c7630 for
> ‘/var/log/syslog’.
Thanks for the report.
That docker image seems to use a quite old coreutils version:
overlayfs - commonly used with Docker cont
Error- tail: unrecognized file system type 0x794c7630 for
‘/var/log/syslog’.
What happened:
First, I git clone a bit bucket repository that contained PHP.
Second, I used git checkout to switch to an existing branch.
Third, I used docker-compose up in my bash terminal.
Finally, I received
On 15/01/2022 01:09, Paul Eggert wrote:
Thanks for reporting that. This is a duplicate of bug#50784[1], which
was fixed[2] in September.
Perhaps we should generate a new Coreutils soon, since this bug has been
reported three times now.
[1]: https://bugs.gnu.org/50784
[2]:
Thanks for reporting that. This is a duplicate of bug#50784[1], which
was fixed[2] in September.
Perhaps we should generate a new Coreutils soon, since this bug has been
reported three times now.
[1]: https://bugs.gnu.org/50784
[2]:
Hello,
we found a case, where chmod from coreutils 9.0 fails (exit value 1), while the
one from 8.29 succeeds. (exit value 0)
Unfortunately, no (error) message is given, just the exit value is 0 and 1
respectively.
Here is the example:
== 8.29: fine
>chmod --version
chmod (
ok I appreciate the explanation.
On Wed, 29 Dec 2021 at 20:58, Paul Eggert wrote:
> On 12/29/21 12:01, Martin Rixham wrote:
> > What nonsense. I want to parse source code. ')' is not an uncommon line
> of
> > source code. It should work.
>
> Unfortunately, you're asking for what is in general
What nonsense. I want to parse source code. ')' is not an uncommon line of
source code. It should work.
On Wed, 29 Dec 2021 at 19:52, Paul Eggert wrote:
> On 12/29/21 08:31, Davide Brini wrote:
> > I think you need to use '+' before the offending token
>
> Yes. That's a GNU extension. If you
On 12/29/21 12:01, Martin Rixham wrote:
What nonsense. I want to parse source code. ')' is not an uncommon line of
source code. It should work.
Unfortunately, you're asking for what is in general impossible. If the
left argument of ':' could be any string, then the grammar for 'expr'
would
On 12/29/21 08:31, Davide Brini wrote:
I think you need to use '+' before the offending token
Yes. That's a GNU extension. If you want to be portable to any POSIX
implementation, you can use this instead:
expr "X(" : '.*' - 1
A similar example is given in the POSIX spec for 'expr':
On Wed, 29 Dec 2021 12:42:24 +, Martin Rixham
wrote:
> I'm getting an error from the following:
>
> [martin@fedora ~]$ expr ')' : '.*'
> expr: syntax error: unexpected ')'
>
> There also seems to be a similar problem with:
>
> expr '(' : '.*'
I think yo
I'm getting an error from the following:
[martin@fedora ~]$ expr ')' : '.*'
expr: syntax error: unexpected ')'
There also seems to be a similar problem with:
expr '(' : '.*'
Here's the version:
[martin@fedora ~]$ expr --version
expr (GNU coreutils) 8.32
Copyright (C
On Fri, 26 Nov 2021 18:54:54 +0100
Bernhard Voelker wrote:
> On 11/26/21 13:23, Frank Busse wrote:
> > I tried it several times with checking the timestamps/md5sums of the
> > files but after remounting the stick it doesn't happen anymore?! I
> > guess it was a hiccup somewhere else in the
On 11/26/21 04:23, Frank Busse wrote:
I
guess it was a hiccup somewhere else in the system, sorry.
Thanks for following up; closing the bug report.
On 11/26/21 13:23, Frank Busse wrote:
> I tried it several times with checking the timestamps/md5sums of the
> files but after remounting the stick it doesn't happen anymore?! I
> guess it was a hiccup somewhere else in the system, sorry.
Perhaps the USB stick was removed from the system before
On Fri, 26 Nov 2021 12:05:21 +
Chris Elvidge wrote:
> Is your USB stick (V)FAT(32) (or similar) formatted?
It's FAT32.
> > The error is fine but mv deletes /src/foo and keeps mnt/dst/foo,
> > meaning that the data of the new file is lost. Is this the intended
> >
On 26/11/2021 11:07 am, Frank Busse wrote:
Hi,
Given two files: an old version of "foo" on a mounted USB stick:
/mnt/dst/foo
and a new version of "foo" in /src/foo on the system's hard drive. When
I do:
sudo mv /src/foo /mnt/dst/foo
I get the following error:
mv
Hi,
Given two files: an old version of "foo" on a mounted USB stick:
/mnt/dst/foo
and a new version of "foo" in /src/foo on the system's hard drive. When
I do:
sudo mv /src/foo /mnt/dst/foo
I get the following error:
mv: failed to preserve ownership for '/mnt
Thanks for your patience and clarification. I was able to get it working
properly with the latest master:
RUN git clone --branch master --single-branch
https://git.savannah.gnu.org/git/coreutils.git \
&& cd coreutils \
&& export FORCE_UNSAFE_CONFIGURE=1 \
&& ./bootstrap \
&&
On 8/17/21 4:48 PM, softwarebugreports via GNU coreutils Bug Reports wrote:
Thank you for the help! I tried using 8002ca7b56acb46b42eeac4a343e112a8ee283cf
and the latest commits from master
You can't combine the latest Coreutils master commit with old Gnulib
commits like
177.2 gnulib/gnulib-tool: *** Stop.
#10 177.2 ./bootstrap: gnulib-tool failed
#10 ERROR: executor failed running [/bin/sh -c git clone --branch v8.32
--single-branch https://git.savannah.gnu.org/git/coreutils.git && cd
coreutils && git clone https://git.savannah.gnu.or
On 17/08/2021 16:16, Pádraig Brady wrote:
On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote:
I receive the following error when using make with coreutils in a alpine based
docker container:
#10 304.5 parse-datetime.tab.c:658:10: fatal error: parse-datetime.tab.h
On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote:
I receive the following error when using make with coreutils in a alpine based
docker container:
#10 304.0 CC lib/mkdir-p.o
#10 304.1 CC lib/modechange.o
#10 304.1 CC lib/mpsort.o
#10 304.2 CC lib/nproc.o
#10 304.2
I receive the following error when using make with coreutils in a alpine based
docker container:
> #10 304.0 CC lib/mkdir-p.o
> #10 304.1 CC lib/modechange.o
> #10 304.1 CC lib/mpsort.o
> #10 304.2 CC lib/nproc.o
> #10 304.2 CC lib/nstrftime.o
> #10 304.3 CC lib/openat-die.o
ed = false;
+ struct change_status ch;
+ ch.status = CH_NO_STAT;
switch (ent->fts_info)
{
@@ -217,27 +231,23 @@ process_file (FTS *fts, FTSENT *ent)
if (! force_silent)
error (0, ent->fts_errno, _("cannot access %s"),
quoteaf (file_full_
Hi,
I noticed that when running chmod with -v on a dangling symlink the
error message is somewhat random:
> ln -s file-that-does-not-exist lnk
> chmod -w lnk -v
> chmod: cannot operate on dangling symlink 'lnk'
> failed to change mode of 'lnk' from (-) to 777
least two cases:
- the file does not exist, but the parent directory is unwritable
@@ -193,9 +197,9 @@ touch (char const *file)
}
else
{
- if (no_create && errno == ENOENT)
+ if (no_create && utime_errno == ENOENT)
hello,
touch utility telling weird error on file creation on a immutable/ro dir.
apparently, it does not catch/report the first error (EPERM) but only
the second one (ENOENT), when trying to set the time on the non-existing
file.
regards
roland kletzing
sysadmin
root@s900:/tmp# mkdir /tmp
Well it seems that this might actually be related to timezone database
files. My timezone is America/Indianapolis but I noticed when I set the
timezone to America/New_York or UTC that this problem doesn't happen
$ TZ=America/Indianapolis date -d "now - 9001 days"
date: invalid date ‘now -
Further investigating this problem it appears that at least today it
doesn't like going back past September 26th, 1997. But only when the
time delta is specified in years months or days. You can go back
further if it's specified in total amounts of hours minutes or seconds.
$ date -d "now -
I ran the following expecting it to provide me with the date 35 years
ago
date -d "now - 35 years"
Instead I received the error:
date: invalid date ‘now - 35 years’
Testing it further I found that the break point is at 24 years:
$ date --version
date (GNU coreutils) 8.32
Co
Hi Padraig,
On 11/30/20 10:31 PM, Pádraig Brady wrote:
> For my reference, if we were to give explicit diagnosis of the leading '='.
> we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ...
I'd also rather keep it like it is, but if we change something:
we could advance
On 30/11/2020 17:22, Pádraig Brady wrote:
On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote:
Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".
If we were to r
On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote:
Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".
If we were to recognize "-I seconds",
it should ju
Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".
-8601'
Valid arguments are:
- 'hours'
- 'minutes'
- 'date'
- 'seconds'
- 'ns'
Try 'date --help' for more information.
Hey, that is a valid argument for --iso-8601. (But not for -I, so say
that instead.)
...
date (GNU coreutils) 8.32
From the above error message
'hours'
- 'minutes'
- 'date'
- 'seconds'
- 'ns'
Try 'date --help' for more information.
> Hey, that is a valid argument for --iso-8601. (But not for -I, so say
> that instead.)
...
> date (GNU coreutils) 8.32
>From the above error message and from the --help output, one c
$ date -I=seconds
date: invalid argument ‘=seconds’ for ‘--iso-8601’
Hey, that is a valid argument for --iso-8601. (But not for -I, so say
that instead.)
Here is a real invalid argument:
$ date --iso-8601=secondsz
date: invalid argument ‘secondsz’ for ‘--iso-8601’
date (GNU coreutils) 8.32
Ruder Laplace wrote:
> Greetings,
>
> I think I catched a bug related to the day-light saving gap:
> *uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
> Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
> GNU/Linux
> mié nov 25 10:30:29 CET 2020
> lun jun 1
Greetings,
I think I catched a bug related to the day-light saving gap:
*uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
GNU/Linux
mié nov 25 10:30:29 CET 2020
lun jun 1 *12*:00:00 CEST 2020
As far as I think it
Thanks for reporting your recipe for working around all these problems. I've
installed patches for the problems into coreutils and gnulib and am closing the
bug report.
On 11/21/20 3:45 PM, Chris Elvidge wrote:
git commit -m 'build: update gnulib submodule to latest' gnulib 2>&1 | tee -a
On 11/21/20 6:37 AM, Chris Elvidge wrote:
parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long
long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]
That's due to a typo that I recently introduced
On 11/21/20 5:17 AM, Pádraig Brady wrote:
The info in https://bugs.gnu.org/44739 must be incorrect,
and we've two counter checks to it now.
Yes, that sounds right. Closing that bug report.
ul]
On 11/21/20 8:54 PM, Chris Elvidge wrote:
CC test-nl_langinfo-mt.o
test-nl_langinfo-mt.c: In function 'threadN_func':
test-nl_langinfo-mt.c:185:1: error: no return statement in function
returning non-void [-Werror=return-type]
}
^
cc1: all warnings being treated as errors
Makefile:6586
[adding Paul]
On 11/21/20 8:54 PM, Chris Elvidge wrote:
>CC test-nl_langinfo-mt.o
> test-nl_langinfo-mt.c: In function 'threadN_func':
> test-nl_langinfo-mt.c:185:1: error: no return statement in function
> returning non-void [-Werror=return-type]
> }
> ^
> cc
OK All. Thanks for all the help.
Whether the bison (3.0.2 -> 3.7) upgrade was needed seems to be a moot
point.
Berny's mod to the bootstrap process (adding a step just before
configure 'git clean -xdfq && ./bootstrap') got over the first error.
Akim's mod to lib/parse-datetime.y (b
n 'parse_datetime2':
> parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long
> long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]
> parse-datetime.y:2301:25: note: in expansion of macro '_'
This is the only error I spotted, and t
it -m 'build: update gnulib submodule to latest' gnulib
git clean -xdfq && ./bootstrap | tee -a out_bootstrap.2
./configure TIME_T_32_BIT_OK=yes | tee -a out_configure.1
I've got the output of the second bootstrap run (git clean deleted the
first one, I think) and the configure run.
How
Hi all,
> Le 20 nov. 2020 à 16:48, Pádraig Brady a écrit :
>
> See also https://bugs.gnu.org/44739
There, I just read this:
>> I found that I needed to upgrade to Bison v3.7.4 to avoid a build error
>> in stdlib.h where @GNULIB_POSIX_MEMALIGN@ has not been converted by
Still no luck. Same error in parse-datetime.y
Cheers
On 21/11/2020 01:17 pm, Bernhard Voelker wrote:
On 11/20/20 5:38 PM, Chris Elvidge wrote:
Reran the whole thing from git clone etc.
(
git clone git://git.sv.gnu.org/coreutils
cd coreutils
./bootstrap
git submodule foreach git pull origin
Well, that got me a bit further. Thanks.
Now the error from 'make' is:
CC lib/parse-datetime.o
In file included from lib/gettext.h:26:0,
from parse-datetime.y:71:
parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: format '%lld' expects
On 11/20/20 5:38 PM, Chris Elvidge wrote:
> Reran the whole thing from git clone etc.
> (
> git clone git://git.sv.gnu.org/coreutils
> cd coreutils
> ./bootstrap
> git submodule foreach git pull origin master
> git config --global user.email "celvidge...@gmail.com"
> git config --global user.name
/lib/parse-datetime.y:555.9-16: syntax error, unexpected identifier,
expecting string
It chokes on `%define api.pure`.
According to NEWS, this syntax was introduced in 2.4 (2008-11-02).
I have tried to install 2.7 on my system, but I can't (because of
portability issues of vasnprintf that were
e-datetime.y:555.9-16: syntax error, unexpected identifier,
expecting string
It chokes on `%define api.pure`.
According to NEWS, this syntax was introduced in 2.4 (2008-11-02).
I have tried to install 2.7 on my system, but I can't (because of
portability issues of vasnprintf that were not covered b
Hi Pádraig,
> Le 20 nov. 2020 à 15:47, Pádraig Brady a écrit :
>
> On 20/11/2020 14:19, Chris Elvidge wrote:
>> I keep getting
>> ./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
>> expressions
>> #if @GNULIB_ALIGNED_ALLOC@
>&g
On 20/11/2020 15:42, Chris Elvidge wrote:
Updated to bison 3.7; installed in /usr/local/bin
Unfortunately, still the same error
Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
No go.
Thanks.
Did you rerun bootstrap?
What version was /usr/bin/bison ?
See also https://bugs.gnu.org
Updated to bison 3.7; installed in /usr/local/bin
Unfortunately, still the same error
Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
No go.
Thanks.
On 20/11/2020 02:47 pm, Pádraig Brady wrote:
On 20/11/2020 14:19, Chris Elvidge wrote:
I keep getting
./lib/stdlib.h:695:5: error
On 20/11/2020 14:19, Chris Elvidge wrote:
I keep getting
./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_ALIGNED_ALLOC@
^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
expressions
#if @G
I keep getting
./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_ALIGNED_ALLOC@
^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_POSIX_MEMALIGN@
^
when running make i
On 11/16/20 10:58 AM, Christina Palka via GNU coreutils Bug Reports wrote:
I got the following error when attempting to install GraphClust2 using
Docker on Mac.
tail: unrecognized file system type 0x794c7630 for
‘/home/galaxy/logs/uwsgi.log’. please report this to bug-coreut...@gnu.or
Thanks
* Rich Felker:
> Note that in any case, musl's lchmod/fchmodat is not affected since it
> always refuses to change symlink modes; I did this because I was
> worried that chmod on the magic symlink in /proc might pass through
> not just to the symlink it refers to, but to the symlink target if one
On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote:
> On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> > * Paul Eggert:
> >
> > > On 1/22/20 2:05 PM, Rich Felker wrote:
> > >> I think we're approaching a consensus that glibc should fix this too,
> > >> so then it would
On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> * Paul Eggert:
>
> > On 1/22/20 2:05 PM, Rich Felker wrote:
> >> I think we're approaching a consensus that glibc should fix this too,
> >> so then it would just be gnulib matching the fix.
> >
> > I installed the attached patch to
* Paul Eggert:
> On 1/22/20 2:05 PM, Rich Felker wrote:
>> I think we're approaching a consensus that glibc should fix this too,
>> so then it would just be gnulib matching the fix.
>
> I installed the attached patch to Gnulib in preparation for the upcoming
> glibc fix. The patch causes
On 1/22/20 2:05 PM, Rich Felker wrote:
I think we're approaching a consensus that glibc should fix this too,
so then it would just be gnulib matching the fix.
I installed the attached patch to Gnulib in preparation for the upcoming
glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW
On Wed, Jan 22, 2020 at 01:55:57PM -0800, Paul Eggert wrote:
> On 1/22/20 7:08 AM, Florian Weimer wrote:
> >I think you misread what I wrote: lchmod*always* returns ENOSYS. Even
> >if the file is not a symbolic link. Likewise, fchmodat with
> >AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.
>
>
On 1/22/20 7:08 AM, Florian Weimer wrote:
I think you misread what I wrote: lchmod*always* returns ENOSYS. Even
if the file is not a symbolic link. Likewise, fchmodat with
AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.
That's too bad, because coreutils (and many other applications, I
* Rich Felker:
> On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> >> Hmm. The way I read the musl code, the O_PATH descriptor already
>> >> exists. At this point, you can just chmod the O_PATH descriptor, and
>> >> have the kernel report EOPNOTSUPP if the
* Rich Felker:
>> Hmm. The way I read the musl code, the O_PATH descriptor already
>> exists. At this point, you can just chmod the O_PATH descriptor, and
>> have the kernel report EOPNOTSUPP if the file system does not support
>> that.
>
> Oh, you mean the second one after it's already open?
1 - 100 of 948 matches
Mail list logo
