On 2023-09-01 19:52, Paul Eggert wrote:
Yes please. If chmod also does not work coreutils might need more
workarounds.
Just to be clear; please try it on a file where chmod should fail
because you don't own the file and you're not root. chmod should fail
with EPERM in this case; it it fails
On 2023-09-01 16:12, Bruno Haible wrote:
Well, you asked me to try it on / but / is an ext4 FS, not a CIFS FS
on my system. Should I try it also on a directory inside the CIFS mount?
Yes please. If chmod also does not work coreutils might need more
workarounds.
Paul Eggert wrote:
> Good, thanks for confirming that the chmod family does not have a
> similar bug.
Well, you asked me to try it on / but / is an ext4 FS, not a CIFS FS
on my system. Should I try it also on a directory inside the CIFS mount?
> I installed the attached workaround into
Paul Eggert wrote:
> > If you compile and run the attached
> > program on a file that you don't own (e.g., './a.out /'), does it
> > incorrectly issue "Permission denied" instead of "Operation not
> > permitted" diagnostics?
and I replied:
> In this case, the diagnostic is "Operation not
Good, thanks for confirming that the chmod family does not have a
similar bug.
I installed the attached workaround into coreutils master on Savannah.
Please give it a try.From 5f971361608749e1245c5eb12096de2acd32bf83 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 1 Sep 2023 15:05:21
2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> > Well in all case %b can not change semantic in the bash script, since it is
> > there for so long, even if it depart from python, perl, libc, it is
> > unfortunate but that's the way it is, nobody want a semantic
Paul Eggert wrote:
> If you compile and run the attached
> program on a file that you don't own (e.g., './a.out /'), does it
> incorrectly issue "Permission denied" instead of "Operation not
> permitted" diagnostics?
In this case, the diagnostic is "Operation not permitted" (from EPERM):
$
On 2023-09-01 08:09, Bruno Haible wrote:
It applies to all 4 variants, as can be seen from applying it to a directory:
$ ./a.out /media/nas/bruno/dir1
lchown: Permission denied
fchownat: Permission denied
chown: Permission denied
fchown: Permission denied
Thanks, for coreutils it'd be helpful
If compatibility with C is really that important,
shouldn't we be fixing %c? Its current behaviour as a synonym for %.1s
doesn't provide significant utility, and arguably differs from C's "take an
int and output the corresponding single byte", not "take the first byte of
a string and output that".
Hello Bruno
thanks for the fast response and for the update suggestion.
Atm we are at openssl-3, but this bug was discovered by
chance, because a package I was testing forced the downgrade
to openssl-1
Agostino
2023-09-01 07:15:14 -0500, Eric Blake:
[...]
> > Note that in bash, you need both
> >
> > shopt -s xpg_echo
> > set -o posix
> >
> > To get a XSI echo. Without the latter, options are still
> > recognised. You can get a XSI echo without those options with:
> >
> > xsi_echo() {
> > local IFS='
Paul Eggert wrote:
> it'd be helpful to know whether the bug is limited to fchownat or
> (as I suspect) applies also to the other chown variants. Could you try
> running the attached program on your platform, to see whether the bug
> affects these other variants?
It applies to all 4 variants,
Thanks for the followup. I looked into fixing it in Gnulib and it
appears that this would require an extra syscall (or maybe even two) per
file when copying to a CIFS filesystem, which I'd rather avoid. So I'm
leaning more towards working around the bug in coreutils. Before doing
that, it'd be
Sam James wrote:
> Forwarding a downstream report at https://bugs.gentoo.org/913368
> of coreutils-9.4 failing to build with openssl-1.1.x:
> """
> x86_64-pc-linux-gnu-gcc -I. -I./lib -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H
> -Ilib -I./lib -Isrc -I./src-O2 -march=x86-64 -pipe -pipe
>
On Fri, Sep 01, 2023 at 07:19:13AM +0200, Phi Debian wrote:
> Well after reading yet another thread regarding libc_printf() I got to
> admit that even %B is crossed out, (Yet already choosen by ksh93)
>
> The other thread also speak about libc_printf() documentting %# as
> undefined for things
On Fri, Sep 01, 2023 at 08:59:19AM +0100, Stephane Chazelas wrote:
> 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
> [...]
> > The current POSIX says that %b was added so that on a non-XSI
> > system, you could do:
> >
> > my_echo() {
> > printf %b\\n "$*"
> > }
>
Hello,
Forwarding a downstream report at https://bugs.gentoo.org/913368
of coreutils-9.4 failing to build with openssl-1.1.x:
"""
x86_64-pc-linux-gnu-gcc -I. -I./lib -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H
-Ilib -I./lib -Isrc -I./src-O2 -march=x86-64 -pipe -pipe
-frecord-gcc-switches
2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> The current POSIX says that %b was added so that on a non-XSI
> system, you could do:
>
> my_echo() {
> printf %b\\n "$*"
> }
That is dependant on the current value of $IFS. You'd need:
xsi_echo() (
IFS=' '
2023-09-01 09:44:08 +0300, Oğuz via austin-group-l at The Open Group:
> On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote:
> > My vote is for posix_printf %B mapping to libc_printf %b
>
> In the shell we already have bc for base conversion. Does POSIX really
> have to support C2x %b in the first
On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote:
> My vote is for posix_printf %B mapping to libc_printf %b
In the shell we already have bc for base conversion. Does POSIX really
have to support C2x %b in the first place?
2023-09-01 07:13:36 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
> 2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> > In today's Austin Group call, we discussed the fact that printf(1) has
> > mandated behavior for %b (escape sequence processing
On Thu, Aug 31, 2023 at 9:11 PM Chet Ramey wrote:
>
> I doubt I'd ever remove %b, even in posix mode -- it's already been there
> for 25 years.
>
>
> Neither one is a very good choice, but `#' is the better one. It at least
> has a passing resemblence to the desired functionality.
>
> Why not
Well after reading yet another thread regarding libc_printf() I got to
admit that even %B is crossed out, (Yet already choosen by ksh93)
The other thread also speak about libc_printf() documentting %# as
undefined for things other than a, A, e, E, f, F, g, and G, yet the same
thread also talk
2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> In today's Austin Group call, we discussed the fact that printf(1) has
> mandated behavior for %b (escape sequence processing similar to XSI
> echo) that will eventually conflict with C2x's desire to introduce %b
> to
24 matches
Mail list logo
