> "PB" == Pádraig Brady writes:
PB> All good suggestions. I'll at least add an example along the lines of:
PB> awk '{print $NF, $0}' | sort -k1,1 | cut -f2- -d' '
OK, also say what it's doing. Not everybody knows awk.
Also join(1) needs a tip added. Users might want to join on
e.g., the
The join main page is really clear,
-o FORMAT
obey FORMAT while constructing output line
A base hit on the first pitch. The info page on the other hand,
‘-o FIELD-LIST’
‘-o auto’
If the keyword ‘auto’ is specified, infer the output format from
the first line in
The join info pages have tons of trailing whitespace.
sed s/$/$/ reveals:
‘sort -u file1 file2’Union of unsorted files$
$
‘sort file1 file2 | uniq -d’ Intersection of unsorted files$
$
‘sort file1
(info "(coreutils) Sorting files for join") needs to talk about numeric
order.
$ seq 111|join --check-order - /dev/null
join: -:10: is not sorted: 10
So the info manual needs to mention 'Even though your files might be in
perfect "sort --numeric-sort" order, you need to make them into plain
Hello.
rm -r while deleting a directory that's longer than PATH_MAX walks it in
a way to avoid hitting max limit
$ (for i in `seq 1 2000`; do mkdir
1234567890123456789012345678901234567890; cd
1234567890123456789012345678901234567890; done)
$ rm -r 1234567890123456789012345678901234567890
(resend)
When analyzing file accesses with strace, I noticed that ln stats an
unrelated file. This only happens with the opions -sfr and when the dest
symlink already exists.
Here's a reproduction script:
# setup
mkdir -p a b
> b/x
ln -fs anything a/x
# ln -sfr b/x a/x
When analyzing file accesses with strace, I noticed that ln stats an
unrelated file. This only happens with the opions -sfr and when the dest
symlink already exists.
Here's a reproduction script:
# setup
mkdir -p a b
> b/x
ln -fs anything a/x
# ln -sfr b/x a/x
strace
On 23/04/2024 11:14, Dan Jacobson wrote:
In (info "(coreutils) sort invocation") be sure to add an example of a
way or workaround for counting fields from the end of the line. E.g., we
want to sort on the last field, but don't know for sure how many fields
a line might contain. E.g., sort by
In (info "(coreutils) sort invocation") be sure to add an example of a
way or workaround for counting fields from the end of the line. E.g., we
want to sort on the last field, but don't know for sure how many fields
a line might contain. E.g., sort by surname, when lines consist of First
On 2024-04-19 11:40, Ionut Nicula wrote:
The following command hangs indefinitely, as expected:
tail -c 4096 /dev/random
The following command immediately returns 4097 bytes, unexpectedly:
tail -c 4097 /dev/random
Thanks for the bug report. Although the two commands should
The following command hangs indefinitely, as expected:
tail -c 4096 /dev/random
The following command immediately returns 4097 bytes, unexpectedly:
tail -c 4097 /dev/random
Details:
- Source code obtained from: git://git.sv.gnu.org/coreutils
- Commit id:
On Fri, 19 Apr 2024 00:33:52 -0700
Paul Eggert wrote:
> On 2024-04-18 14:52, Sergei Trofimovich wrote:
> > $ clang simple.c -o simple && echo 42 | ./simple
> > 1: ino=3009428657538693161
> > 2: ino=3009428657538693161
> > 3: ino=1568241705
> >
> > Note how stat() and fstat() don't agree on
On 2024-04-18 14:52, Sergei Trofimovich wrote:
$ clang simple.c -o simple && echo 42 | ./simple
1: ino=3009428657538693161
2: ino=3009428657538693161
3: ino=1568241705
Note how stat() and fstat() don't agree on inode.
Apparently it's documented in
On 4/18/24 14:52, Sergei Trofimovich wrote:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fstat.2.html
as
BUGS
Applying fstat to a socket (and thus to a pipe) returns a zero'd buffer,
except for the blocksize field, and a
Hi Sergei,
On Thu, Apr 18, 2024 at 10:52:32PM +0100, Sergei Trofimovich wrote:
> > The system I have locally is this one:
> >
> > $ uname -a
> > Darwin tests-iMac.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Jun 22
> > 19:37:08 PDT 2021; root:xnu-4903.278.70~1/RELEASE_X86_64 x86_64
>
On Tue, 16 Apr 2024 22:37:58 +0100
Sergei Trofimovich wrote:
> On Tue, 16 Apr 2024 12:33:44 +0100
> Pádraig Brady wrote:
>
> > On 16/04/2024 01:19, Alejandro Colomar wrote:
> > > Hi!
> > >
> > > I don't own a Darwin system, so I can't help much reproduce. However,
> > > I've received a bug
On 4/17/24 03:19, Pádraig Brady wrote:
Patch looks good, and conforms to POSIX.
Thanks for the review. I installed the patch and am closing this bug report.
On 16/04/2024 23:17, Paul Eggert wrote:
On 4/16/24 14:30, Toby Kelsey wrote:
The man page doesn't explain this format conflict, while the info page
(info '(coreutils) ls invocation' or 'info ls') claims '-f' implies '-1'
which is also incorrect: 'ls -1f' gives different output to to 'ls -f'.
Thanks for the clarification and patch
On 16/04/2024 at 23:17, Paul Eggert wrote:
On 4/16/24 14:30, Toby Kelsey wrote:
The man page doesn't explain this format conflict, while the info page
(info '(coreutils) ls invocation' or 'info ls') claims '-f' implies
'-1' which is also incorrect: 'ls
On 4/16/24 14:30, Toby Kelsey wrote:
The man page doesn't explain this format conflict, while the info page
(info '(coreutils) ls invocation' or 'info ls') claims '-f' implies '-1'
which is also incorrect: 'ls -1f' gives different output to to 'ls -f'.
Yes, this area of GNU 'ls' a mess.
On Tue, 16 Apr 2024 12:33:44 +0100
Pádraig Brady wrote:
> On 16/04/2024 01:19, Alejandro Colomar wrote:
> > Hi!
> >
> > I don't own a Darwin system, so I can't help much reproduce. However,
> > I've received a bug report to the Linux man-pages, that our build
> > system (GNUmakefile-based),
The man page doesn't explain this format conflict, while the info page (info '(coreutils) ls invocation' or 'info ls')
claims '-f' implies '-1' which is also incorrect: 'ls -1f' gives different output to to 'ls -f'.
I am using coreutils 9.4-3 in Manjaro and the online documentation for 9.5
On 4/16/24 12:44, Pádraig Brady wrote:
A related suggestion was from Marc Chantreux (CC'd)
to support '-' to imply stdin, which would be more portable.
There is some merit to that suggestion too.
I see that merit too, as when 'install' reads from stdin it needn't do
the inode check. However,
Hi,
On Tue, Apr 16, 2024 at 08:44:06PM +0100, Pádraig Brady wrote:
> I agree if it's older Darwin only, we can ignore.
> The version I tested on is 3 years old now though,
> so I'm not sure whether the issue is on newer or older.
>
> Note we had similar issue on Solaris,
> where we used an
On 4/16/24 07:47, Alejandro Colomar wrote:
Since you couldn't reprodude it in a recent Darwin, maybe it's
just a bug in an old Darwin.
It'd have to be pretty old. As near as I can see from
xnu/bsd/kern/sys_pipe.c, the st_ino field was zero (i.e., not random)
even in xnu-792 dated 2005.
I'd
On 16/04/2024 15:47, Alejandro Colomar wrote:
Hi Pádraig,
On Tue, Apr 16, 2024 at 03:25:22PM +0100, Pádraig Brady wrote:
What version of darwin is this? I can't repro on Darwin 21.6.0 (MacOSX 12.6).
The issue seems to be that /dev/stdin returns a varying inode which install(1)
doesn't like
On 16/04/2024 at 16:07, Toby Kelsey wrote:
There appears to be a bug with 'ls' when using the '-f' and '-l'
options, or at least an inconsistency with the man page. The man page
says '-f' list entries in directory order and does not mention any
incompatibilities with other options, however
There appears to be a bug with 'ls' when using the '-f' and '-l' options, or at least an inconsistency with the man
page. The man page says '-f' list entries in directory order and does not mention any incompatibilities with other
options, however I find using it with the '-l' option gives
Hi Pádraig,
On Tue, Apr 16, 2024 at 03:25:22PM +0100, Pádraig Brady wrote:
> > What version of darwin is this? I can't repro on Darwin 21.6.0 (MacOSX
> > 12.6).
> > The issue seems to be that /dev/stdin returns a varying inode which
> > install(1) doesn't like currently
I don't know. The
On 16/04/2024 12:33, Pádraig Brady wrote:
On 16/04/2024 01:19, Alejandro Colomar wrote:
Hi!
I don't own a Darwin system, so I can't help much reproduce. However,
I've received a bug report to the Linux man-pages, that our build
system (GNUmakefile-based), which ends up calling
... |
On 16/04/2024 01:19, Alejandro Colomar wrote:
Hi!
I don't own a Darwin system, so I can't help much reproduce. However,
I've received a bug report to the Linux man-pages, that our build
system (GNUmakefile-based), which ends up calling
... | install /dev/stdin $@
doesn't work on
Hi!
I don't own a Darwin system, so I can't help much reproduce. However,
I've received a bug report to the Linux man-pages, that our build
system (GNUmakefile-based), which ends up calling
... | install /dev/stdin $@
doesn't work on Darwin. Here's the original bug report:
On 15/04/2024 15:37, Andreas Grünbacher wrote:
Hello,
Am So., 14. Apr. 2024 um 00:43 Uhr schrieb Pádraig Brady :
On 13/04/2024 20:29, Bruno Haible wrote:
Hi Pádraig,
I wrote:
5) The same thing with 'cp -a' succeeds:
$ build-sparc64/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
0
$
Hello,
Am So., 14. Apr. 2024 um 00:43 Uhr schrieb Pádraig Brady :
> On 13/04/2024 20:29, Bruno Haible wrote:
> > Hi Pádraig,
> >
> > I wrote:
> >>> 5) The same thing with 'cp -a' succeeds:
> >>>
> >>> $ build-sparc64/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
> >>> 0
> >>> $
On 13/04/2024 20:29, Bruno Haible wrote:
Hi Pádraig,
I wrote:
5) The same thing with 'cp -a' succeeds:
$ build-sparc64/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
0
$ build-sparc64-no-acl/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
0
You wrote:
The psuedo code that install(1)
Hi Pádraig,
I wrote:
> > 5) The same thing with 'cp -a' succeeds:
> >
> > $ build-sparc64/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
> > 0
> > $ build-sparc64-no-acl/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
> > 0
You wrote:
> The psuedo code that install(1) uses is:
>
>
On 13/04/2024 17:39, Pádraig Brady wrote:
install(1) defaults to mode 600 for new files, and uses set_acl() with that
(since 2007 https://github.com/coreutils/coreutils/commit/f634e8844 )
The psuedo code that install(1) uses is:
copy_reg()
if (x->set_mode) /* install */
set_acl(dest,
On 05/04/2024 10:48, Bruno Haible wrote:
Hi,
The 'install' program from coreutils-9.5 fails to copy a regular file
from an ext4 mount to an autofs/cifs mount.
The same operation, with 'cp -a', works fine.
Also, it works fine when coreutils was built with the configure options
"--disable-acl
Things have changed a little since the original request.
alacritty sets $COLORTERM, and dircolors now auto accepts that since:
https://github.com/coreutils/coreutils/commit/75c9fc674
There are some complications with remote shells, but
they should boil down to setting up ssh to send/accept
On 4/9/24 2:21 PM, Pádraig Brady wrote:
Thanks for looking at this.
From the Fedora side, they dropped a Fedora specific patch for Fedora 38.
https://bugzilla.redhat.com/show_bug.cgi?id=548834
https://bugzilla.redhat.com/show_bug.cgi?id=2208048
FWIW: OpenSUSE still has that patch which was
I am not trying to spam this mailing list, but I received several DMARC
reports after sending the previous mail (never happened to me before, no
idea why).
So I am trying again from a different domain, in case the email wasn't
received at all.
Sorry for the inconvenience.
Regards
Eike Gebauer
On 09/04/2024 10:17, Collin Funk wrote:
On 4/9/24 12:57 AM, Paul Eggert wrote:
Indeed there is, and I merged your bug report into that old one. It'd be nice
if someone could get to the bottom of that bug.
I decided to look into this a bit, since I also have an unknown
'uname -i' and 'uname
On 4/9/24 12:57 AM, Paul Eggert wrote:
> Indeed there is, and I merged your bug report into that old one. It'd be nice
> if someone could get to the bottom of that bug.
I decided to look into this a bit, since I also have an unknown
'uname -i' and 'uname -p'.
It seems that this option is a
On 2024-04-08 10:59, Ondrej Mejzlik wrote:
The command uname returns "unknown" on Fedora 38,39 and probably 40.
There is a similar very old bug here which has not been fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34905
Indeed there is, and I merged your bug report into that old one.
The command uname returns "unknown" on Fedora 38,39 and probably 40.
There is a similar very old bug here which has not been fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34905
F38:
[root@vm~]# uname -a
Linux vmcom 6.8.4-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 4
20:40:57 UTC 2024
On 06/04/2024 23:22, Paul Eggert wrote:
On 2024-04-06 03:09, Pádraig Brady wrote:
I'll apply this.
Heh, I beat you to it by looking for similar errors elsewhere and
applying the attached patches to fix the issues I found. None of them
look like serious bugs.
Cool. I thought the sort(1)
On 2024-04-06 03:09, Pádraig Brady wrote:
I'll apply this.
Heh, I beat you to it by looking for similar errors elsewhere and
applying the attached patches to fix the issues I found. None of them
look like serious bugs.
BTW we should improve sort buffer handling in general
Oh yes.
PS.
tag 70219 notabug
close 70219
stop
On 06/04/2024 16:50, Branden R. Williams via GNU coreutils Bug Reports wrote:
-k, --kill-after=DURATION
also send a KILL signal if COMMAND is still running
this long after the initial signal was sent
If you read the
Working from the code published here:
https://github.com/coreutils/coreutils/blob/master/src/timeout.c
If you look at the code, you can see the kill_after variable set on line 486 if
the switch is there. In the cleanup() function on line 202, it looks for that
variable to be st on line 212,
I understand this, but the manpage and the help file do not explain the
functionally this way. The manpage suggests that the following should work:
$ timeout -k 10s sleep 10
It does not because the first argument after -k MUST be the an integer value of
the signal you want to send, not the
Branden,
Then how come timeout -k 10s 20s ping 8.8.8.8 works?
10s is DEFINITELY NOT an integer. 20s in the timeout value.
I still think your reasoning is suspect.
On 06/04/2024 at 13:43, Branden R. Williams wrote:
I understand this, but the manpage and the help file do not explain the
On 06/04/2024 03:52, Takashi Kusumi wrote:
Hi,
I have found a performance issue with the sort command when used on
pseudo files with zero size. For instance, sorting `/proc/kallsyms`, as
demonstrated below, takes significantly longer than executing with
`cat`, generating numerous temporary
On Apr 05 2024, "Branden R. Williams" via GNU coreutils Bug Reports wrote:
> That’s not an accurate representation of what the command actually does. The
> argument after -k MUST be the kill signal code, without the code the command
> fails. The manpage and help document agree with what you are
Hi,
I have found a performance issue with the sort command when used on
pseudo files with zero size. For instance, sorting `/proc/kallsyms`, as
demonstrated below, takes significantly longer than executing with
`cat`, generating numerous temporary files. I confirmed this issue on
v8.32 as well
That’s not an accurate representation of what the command actually does. The
argument after -k MUST be the kill signal code, without the code the command
fails. The manpage and help document agree with what you are saying but the
execution of the program fails.
That functionality is not
On 05/04/2024 at 16:19, Branden R. Williams via GNU coreutils Bug
Reports wrote:
I was integrating the timeout command into a shell script and realized the manpage
& the --help docs do not accurately describe how the tool works. In addition,
there appears to be a bug related to arguments
I was integrating the timeout command into a shell script and realized the
manpage & the --help docs do not accurately describe how the tool works. In
addition, there appears to be a bug related to arguments passed. I am running
version 9.1.
According to the help screen, this command should
Hi,
The 'install' program from coreutils-9.5 fails to copy a regular file
from an ext4 mount to an autofs/cifs mount.
The same operation, with 'cp -a', works fine.
Also, it works fine when coreutils was built with the configure options
"--disable-acl --disable-xattr".
How to reproduce
On 01/04/2024 16:30, Petr Pisar wrote:
Hello,
while translating coreutils-9.5-pre2 I noticed this message:
#: src/chown.c:123
msgid ""
" --reference=RFILE use RFILE's ownership rather than specifying values\n"
" RFILE is always dereferenced if a symbolic link.\n"
Hello,
while translating coreutils-9.5-pre2 I noticed this message:
#: src/chown.c:123
msgid ""
" --reference=RFILE use RFILE's ownership rather than specifying values\n"
" RFILE is always dereferenced if a symbolic link.\n"
I believe that there is missing a full
On 2024-03-31 12:45, Bruno Haible wrote:
I think you must ask this to yourself:
- What caused you to change the unit tests on 2023-09-04?
- How is the musl version that you used on that date configured?
What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19.
- Did you
Adept's Lab wrote:
> >> test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
Thanks for the report. I reproduce it with gnulib testdirs
$ rm -rf ../testdir1; ./gnulib-tool --create-testdir --dir=../testdir1
--single-configure canonicalize-lgpl
$ rm -rf ../testdir2;
On 3/31/24 05:22, Pádraig Brady wrote:
On 31/03/2024 10:02, Adept's Lab wrote:
test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
^ the only error log message I get. Fail was not presented with previous
stable versions.
This is on musl 1.1.24 as detailed at:
On 31/03/2024 10:02, Adept's Lab wrote:
test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
^ the only error log message I get. Fail was not presented with previous
stable versions.
This is on musl 1.1.24 as detailed at:
https://github.com/coreutils/coreutils/issues/83
test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
^ the only error log message I get. Fail was not presented with previous
stable versions.
On 3/29/24 08:15, Andreas Schwab wrote:
On Mär 29 2024, Bruno Haible wrote:
Yes. And make sure that it has a time zone database installed at all.
Why? That doesn't make any sense.
Although Andreas is not clear, perhaps he is alluding to the fact that
Gnulib's localtime_r tests assume that
Andreas Schwab wrote:
> > Yes. And make sure that it has a time zone database installed at all.
>
> Why? That doesn't make any sense.
You can leave the consideration of which test case makes sense or not
on my side.
What we need from you, as a reporter, is a statement on which
platform (distro
On Mär 29 2024, Bruno Haible wrote:
> Yes. And make sure that it has a time zone database installed at all.
Why? That doesn't make any sense.
Andreas Schwab wrote:
> > FAIL: test-localtime_r
> > ==
> >
> > test-localtime_r.c:58: assertion 'result->tm_hour == 18' failed
> > FAIL test-localtime_r (exit status: 134)
> >
> > FAIL: test-localtime_r-mt
> > =
> >
> > thread2 disturbed by thread1!
On 29/03/2024 12:40, Andreas Schwab wrote:
FAIL: test-localtime_r
==
test-localtime_r.c:58: assertion 'result->tm_hour == 18' failed
FAIL test-localtime_r (exit status: 134)
FAIL: test-localtime_r-mt
=
thread2 disturbed by thread1!
thread1 disturbed
FAIL: test-localtime_r
==
test-localtime_r.c:58: assertion 'result->tm_hour == 18' failed
FAIL test-localtime_r (exit status: 134)
FAIL: test-localtime_r-mt
=
thread2 disturbed by thread1!
thread1 disturbed by thread2!
FAIL test-localtime_r-mt (exit
By now alacritty has been packaged for Fedora for quite a while
(https://packages.fedoraproject.org/pkgs/rust-alacritty/alacritty/) and
is used by a relatively large community (>50k Stars on Github).
The corresponding issue on the alacritty side has sadly been closed as
"wontfix"
On 25/03/2024 14:02, Göran Uddeborg wrote:
While translating the new version of coreutils to Swedish, I came
across this code from the end of chown-core.h:
printf (_("\
--from=CURRENT_OWNER:CURRENT_GROUP\n\
change the %sgroup of each file only if\n\
While translating the new version of coreutils to Swedish, I came
across this code from the end of chown-core.h:
printf (_("\
--from=CURRENT_OWNER:CURRENT_GROUP\n\
change the %sgroup of each file only if\n\
its current owner and/or group
On 24/03/2024 16:57, Frédéric Marchal wrote:
Hi,
In src/chown-core.h:95 (coreutils-9.5-pre1), the following message is
impossible to translate as it is created by concatenating string fragments:
static inline void
emit_from_option_description (bool user)
{
printf (_("\
Hi,
In src/chown.c:79 (coreutils-9.5-pre1.fr.po), some part of the sting was moved
to an untranslated argument:
printf (_("\
Usage: %s [OPTION]... %s FILE...\n\
or: %s [OPTION]... --reference=RFILE FILE...\n\
"),
program_name,
chown_mode == CHOWN_CHOWN ?
Hi,
In src/chown-core.h:95 (coreutils-9.5-pre1), the following message is
impossible to translate as it is created by concatenating string fragments:
static inline void
emit_from_option_description (bool user)
{
printf (_("\
--from=CURRENT_OWNER:CURRENT_GROUP\n\
On 24/03/2024 12:40, Stephane Chazelas wrote:
Tags: patch
My bad, the patch was incorrect, it should have said
"replaced by the corresponding device major and minor numbers as two decimal
numbers separated by a comma and at least one space.", as
there's not always only once space between the
Tags: patch
My bad, the patch was incorrect, it should have said
"replaced by the corresponding device major and minor numbers as two decimal
numbers separated by a comma and at least one space.", as
there's not always only once space between the major and minor.
See also
Package: coreutils
Version: 9.4
Tags: patch
The ls documentation currently doesn't state that for device
files, the size field in the long listing format is replaced by
major, minor.
Patch attached.
--
Stephane
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 8a2104831..c8e3bd110
Hi,
indeed, the issue seems to be in libc. I can reproduce the problem with
a simple C program:
#include
#include
#include
int main(int argc, char** argv)
{
setlocale (LC_ALL, "");
struct lconv* loc = localeconv();
printf("Thousands Separator: <%s>\n", loc->thousands_sep);
Hi,
some further debugging of a hexdump output of printf, i.e.:
#!/bin/bash
for l in de_DE en_US nb_NO nn_NO ; do
echo "LC_NUMERIC=$l.UTF-8"
for n in 1 100 1000 1 10 100 1000 ; do
LC_NUMERIC=$l.UTF-8 /usr/bin/printf "<%'10d>" $n | hexdump -C
done
done
The output
tag 69951 notabug
close 69951
stop
On 22/03/2024 20:22, Thomas Dreibholz wrote:
Hi,
I just discovered a printf bug for at least the nb_NO and nn_NO locales
when printing numbers with thousands separator. To reproduce:
#!/bin/bash
for l in de_DE nb_NO ; do
echo "LC_NUMERIC=$l.UTF-8"
On 3/22/24 11:22, Karel Zak wrote:
> On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:>> On
userland OTOH, we have broader choice.
>> Karel did his choice in util-linux for exch(1), and coreutils could expose
>> the same functionality.
>>
>> For other feature requests, we were
On 3/23/24 02:44, Paul Eggert wrote:
I installed the attached patches to do the above. (Basically, the
problem was that my earlier patches were too ambitious; these patches
scale things back to avoid some optimizations so that mv --exchange is
more like ordinary mv.)
The first patch simplifies
On 3/21/24 14:45, Bernhard Voelker wrote:
On 3/21/24 00:56, Paul Eggert wrote:
On 3/20/24 15:53, Bernhard Voelker wrote:
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.
There's another which is not
Hi,
I just discovered a printf bug for at least the nb_NO and nn_NO locales
when printing numbers with thousands separator. To reproduce:
#!/bin/bash
for l in de_DE en_US nb_NO ; do
echo "LC_NUMERIC=$l.UTF-8"
for n in 1 100 1000 1 10 100 1000 ; do
On Mär 22 2024, Pádraig Brady wrote:
> Though I see bash 5.2.26 has issue with it :/
>
> $ test \( -a \) -a \( -a \)
> bash: test: `)' expected
>
> bash doesn't like the -a in particular, and is ok with other strings:
That's because in bash -a is ambiguous:
-a FILETrue if file
On 22/03/2024 11:20, Vincent Lefevre wrote:
With GNU Coreutils 9.4, both "test -a -a -a" and "test -o -o -o" fail:
$ export POSIXLY_CORRECT=1
$ /usr/bin/test -a -a -a ; echo $?
/usr/bin/test: ‘-a’: unary operator expected
2
$ /usr/bin/test -o -o -o ; echo $?
/usr/bin/test: ‘-o’: unary operator
With GNU Coreutils 9.4, both "test -a -a -a" and "test -o -o -o" fail:
$ export POSIXLY_CORRECT=1
$ /usr/bin/test -a -a -a ; echo $?
/usr/bin/test: ‘-a’: unary operator expected
2
$ /usr/bin/test -o -o -o ; echo $?
/usr/bin/test: ‘-o’: unary operator expected
2
According to POSIX, they should
On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:
> On userland OTOH, we have broader choice.
> Karel did his choice in util-linux for exch(1), and coreutils could expose
> the same functionality.
>
> For other feature requests, we were much more reluctant in coreutils ... for
>
On 3/21/24 00:56, Paul Eggert wrote:
On 3/20/24 15:53, Bernhard Voelker wrote:
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.
There's another which is not consistent with/without --exchange:
$
On 14/03/2024 20:31, Douglas McIlroy wrote:
Multicolumn options in pr imply option -i (tabification). The introduction
of tabs with physical rather than logical meaning makes output that is OK
for viewing only if you have correct tab stops, and is complicated for
further processing. It caters
On 3/20/24 15:53, Bernhard Voelker wrote:
$ echo 1 > a
$ mkdir d
$ echo 2 > d/a
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
$ cat a
2
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
On 3/20/24 14:43, Bernhard Voelker wrote:
> On 3/17/24 07:10, Paul Eggert wrote:
> Now, extending "exchange" to more arguments is confusing and the
> use is not intuitive:
>mv -v --exchange a b c d
It's also pointless. An atomic exchange on more than 2 files ISN'T ATOMIC.
That's why I didn't
On 3/20/24 21:56, Paul Eggert wrote:
On 3/20/24 12:43, Bernhard Voelker wrote:
This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more
On 3/17/24 04:32, Pádraig Brady wrote:
I think the --no-copy situation is brittle, as scripts not using it now
would be atomic, but then if we ever supported cross fs swaps
it may become non atomic. I'd at least doc with a line in the --exchange
description in usage() to say something like:
On 3/20/24 12:43, Bernhard Voelker wrote:
This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.
Yes, that's mv's original sin,
On 3/17/24 07:10, Paul Eggert wrote:
Although removing that "mv --swap" implementation was a win, I don't
think we can simply delegate this to util-linux's exch command.
I still have some headache adding this.
This stems from the fact that although mv(1) is a userland frontend
for
On 16/12/2011 16:29, Jan Engelhardt wrote:
Hi,
chown(1) has a -h option by which it affects symlinks directly rather
than the pointed-to file. The bonus side effect is that the
pointed-to files don't get changed in any way, which is kinda welcome
if you attempt to "fix" permissions/ownership in
1 - 100 of 29325 matches
Mail list logo
