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
On 28/03/2012 21:28, Paul Eggert wrote:
On 03/28/2012 01:13 PM, Jim Meyering wrote:
$ ./chmod u+w f
./chmod: changing permissions of 'f': Operation not supported
Yeouch. I undid the change for now.
Hmm, why did "make check" work for me?
I'll have to investigate later, alas.
Patch
On 3/19/24 08:33, Rafal Maszkowski wrote:
he --debug option advised in
README does not say anything helpful:
(echo a; echo b) | sort --debug -nu
sort: text ordering performed using simple byte comparison
a
^ no match for key
That diagnostic message is helpful. It's telling you that there's no
Sort with -n and -u options works correctly for numbers:
(echo 10; echo 11) | sort -nu
10
11
but looses data when used with non-numbers:
(echo a; echo b) | sort -nu
a
(echo 1.0; echo 1.1) | sort -nu
1.0
I have tested this on versions 8.32 and 9.2 default for Debian 11 and
12, and additionally
I have now reported this upstream since I consider this to be a bug in
the FreeBSD Linux compat layer:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277804
I did some more investigation with stat(2). Running native on FreeBSD
with Python os package 'st_dev':
$ df -t ufs | cut -f 6 -w | sed 1d | xargs -I% python ~/stat.py %
/: 108
/tmp: 110
/var: 111
/var/tmp: 112
/usr: 113
/usr/local: 161
/usr/ports: 142
/usr/obj: 141
/usr/local/pgsql: 140
Disclaimer: I am not 100% certain whether this is a bug in GNU coreutils
or FreeBSD Linux emulation layer because the behavior is weird. So,
please bear with me.
Consider the following output on FreeBSD 13 from FreeBSD's df(1):
$ df -t ufs -b -T -a
Filesystem Type 512-blocks
On 17/03/2024 11:32, Pádraig Brady wrote:
On 17/03/2024 06:10, Paul Eggert wrote:
On 2024-03-05 06:16, Pádraig Brady wrote:
I think I'll remove the as yet unreleased mv --swap from coreutils,
given that
util-linux is as widely available as coreutils on GNU/Linux platforms.
Although removing
On 17/03/2024 06:10, Paul Eggert wrote:
On 2024-03-05 06:16, Pádraig Brady wrote:
I think I'll remove the as yet unreleased mv --swap from coreutils,
given that
util-linux is as widely available as coreutils on GNU/Linux platforms.
Although removing that "mv --swap" implementation was a win,
On 2024-03-05 06:16, Pádraig Brady wrote:
I think I'll remove the as yet unreleased mv --swap from coreutils,
given that
util-linux is as widely available as coreutils on GNU/Linux platforms.
Although removing that "mv --swap" implementation was a win, I don't
think we can simply delegate
On 15/03/2024 05:21, Paul Eggert wrote:
On 2024-03-14 06:03, Pádraig Brady wrote:
How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
is used when the compiler supports -O1? That way we don't have to worry
about running the program, because (with the "volatile") clang will
On 2024-03-14 06:03, Pádraig Brady wrote:
How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
is used when the compiler supports -O1? That way we don't have to worry
about running the program, because (with the "volatile") clang will
error out.
Alternatively perhaps
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 for obsolete equipment--typewriters, on
which
On 3/14/24 7:48 AM, Pádraig Brady wrote:
> For completeness I should add that the above check can be
> overridden if cross-compiling or whatever like:
>
> ./configure utils_cv_ieee_16_bit_supported=yes
> utils_cv_brain_16_bit_supported=yes
Ah, thanks. I wasn't aware of this.
> Interesting.
>
On 14/03/2024 13:35, Collin Funk wrote:
On 3/14/24 6:03 AM, Pádraig Brady wrote:
It would disable this feature for cross-compilation yes,
but this isn't the first instance of AC_RUN_IFELSE we use.
For completeness I should add that the above check can be
overridden if cross-compiling or
On 3/14/24 6:03 AM, Pádraig Brady wrote:
> It would disable this feature for cross-compilation yes,
> but this isn't the first instance of AC_RUN_IFELSE we use.
Sorry if this is not the proper place to ask, but would it be possible
to make Autoconf use an emulator when cross-compiling? This issue
On 14/03/2024 05:59, Paul Eggert wrote:
On 2024-03-12 19:24, Grisha Levit wrote:
- AC_COMPILE_IFELSE(
+ AC_RUN_IFELSE(
This sort of change would break cross-compilation, no?
It would disable this feature for cross-compilation yes,
but this isn't the first instance of AC_RUN_IFELSE we use.
On 2024-03-12 19:24, Grisha Levit wrote:
- AC_COMPILE_IFELSE(
+ AC_RUN_IFELSE(
This sort of change would break cross-compilation, no?
How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
is used when the compiler supports -O1? That way we don't have to worry
about running
On 25/01/2024 19:52, Grisha Levit wrote:
On Thu, Jan 25, 2024, 09:50 Pádraig Brady wrote:
This mostly looks good, except:
- No need to clear the errno before kill(3).
- Better to use SIG%d rather than the bare %d for signal _names_, as we already
parse this format
Makes sense, done below.
On 13/03/2024 02:24, Grisha Levit wrote:
Recent clang provides __bf16 on aarch64 but it is broken.
If built with -O0, the conversion is wrong:
$ printf '\x3F\x80' | od --end=big -An -tfB | tr -d ' '
1.875
If built with -O1 or higher, compilation fails:
fatal error: error in
Recent clang provides __bf16 on aarch64 but it is broken.
If built with -O0, the conversion is wrong:
$ printf '\x3F\x80' | od --end=big -An -tfB | tr -d ' '
1.875
If built with -O1 or higher, compilation fails:
fatal error: error in backend: Cannot select: 0xb47a58d29780: f32
I'm erring on the side of applying this,
though I'm a bit wary of an endlessly expanding list,
as there is no end to what can be compressed for example.
cheers,
Pádraig
* src/dircolors.hin: Add .apk (Alpine Linux/Android package); .drpm
(delta rpm); .egg, .pyz, and .whl (Python related); and .udeb (form of
.deb).
---
src/dircolors.hin | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/dircolors.hin b/src/dircolors.hin
index c85c037a5..58297e8bb 100644
On 2024-03-08 00:49, brian wrote:
Please consider this bug report to be closed. I'm not sure if/how I can
do that via e-mail.
Thanks for following up, and good luck with your hardware or drivers.
Closing the bug report.
On 2024-03-08 05:47, Pádraig Brady wrote:
seq $a | xargs printf -- 'x%.0s'
printf "%${a}s" '' | tr ' ' x
yes x | head -n$a | tr -d '\n'
Oh, I like those! Unfortunately the printf solution silently fails for
me when a=100 due to a bug in Bash. Perhaps I'll get up the
tag 69636 notabug
close 69636
stop
On 08/03/2024 12:29, User wrote:
Jim Meyering wrote:
Paul Eggert wrote:
* src/seq.c (validate_format): Remove. Migrate its checks into...
(long_double_format): Report an error and exit if an error is found,
instead of returning NULL. All callers
Jim Meyering wrote:
Paul Eggert wrote:
> * src/seq.c (validate_format): Remove. Migrate its checks into...
> (long_double_format): Report an error and exit if an error is found,
> instead of returning NULL. All callers changed.
> Use a more-consistent format for diagnostics.
> *
Sorry for the delay in updating this problem - I've been doing some
testing!
The first thing I did was wrote a quick and dirty Pascal program to do
a byte-by-byte comparison of the data files, just in case it was cmp
that was causing the problem, not cp. The results were the same using
my
When I knew RENAME_EXCHANGE, I thought we should extend mv command as
you did: adding --swap. However, after researching the past
challenges, I decided not to propose the feature to coreutils.
https://www.gnu.org/software/coreutils/rejected_requests.html
On Tue, Mar 05, 2024 at 02:16:05PM +, Pádraig Brady wrote:
> I think having the functionality in mv(1) is better than in rename(1),
> but since exch(1) is already released that's probably
> the best place for this functionality now.
>
> A separate exch command may be overkill for just this,
On 05/03/2024 04:10, Paul Eggert wrote:
On 3/4/24 16:43, Dominique Martinet wrote:
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
Busybox does not use RENAME_EXCHANGE, so this isn't a Busybox issue.
Toybox mv added -x to its development
On Mon, Mar 04, 2024 at 04:24:27PM -0800, Paul Eggert wrote:
> On 3/4/24 15:37, Petr Malat wrote:
> > Why do you expect this?
>
> I expect it because mv has always treated destination directories that way.
> This has been true since the 1970s. We should not change this basic mode of
> operation.
On Mon, Mar 04, 2024 at 08:35:03PM +, P??draig Brady wrote:
> On 04/03/2024 15:47, P??draig Brady wrote:
> > On 04/03/2024 00:44, Paul Eggert wrote:
> > > Although I like the idea of exposing file swaps to the user, the first
> > > cut of 'mv -x' has significant problems.
> > >
> > > I expect
Hi Paul,
On Sun, Mar 03, 2024 at 04:44:52PM -0800, Paul Eggert wrote:
> Although I like the idea of exposing file swaps to the user, the first cut
> of 'mv -x' has significant problems.
>
> I expect 'mv -x A B' to act like 'mv A B' except the destination must exist
> and is renamed back to A.
On 3/4/24 18:43, Dominique Martinet wrote:
> Adding Rob to the loop because this impacts compatibility with
> toybox/maybe busybox implementations
> (Quoting in full for convenience, there's a few more mails in
> https://lists.nongnu.org/archive/html/bug-coreutils/2024-03/msg2.html
> but we
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
(Quoting in full for convenience, there's a few more mails in
https://lists.nongnu.org/archive/html/bug-coreutils/2024-03/msg2.html
but we seem to be missing Petr's reply)
Pádraig Brady wrote
Paul Eggert wrote on Mon, Mar 04, 2024 at 08:10:35PM -0800:
> so there's little prior art there, and there's still plenty of time to fix
> its problems before exposing it to the world.
Yes, I just meant that everyone should agree, or there's little point in
implementing these for toybox/busybox,
On 3/4/24 12:35, Pádraig Brady wrote:
Another point worth mentioning before changing this,
is that changing would make the --swap operation non symmetric.
I.e. `mv -x a d` would be different to `mv -x d a` where d in a directory.
Yes, of course. It's just like mv without the -x. After you've
On 3/4/24 16:43, Dominique Martinet wrote:
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
Busybox does not use RENAME_EXCHANGE, so this isn't a Busybox issue.
Toybox mv added -x to its development version yesterday:
On 3/4/24 15:37, Petr Malat wrote:
Why do you expect this?
I expect it because mv has always treated destination directories that
way. This has been true since the 1970s. We should not change this basic
mode of operation.
To fix this, 'mv -x' should respect the usual mv behavior with
On 3/4/24 15:16, Petr Malat wrote:
I prefer KISS principle and allowing
swapping just 2 paths.
In that case, the option should be added to the 'rename' command, not to
'mv'.
It is not KISS to add an option to 'mv' that makes it act completely
differently, such that most of mv's other
On 04/03/2024 15:47, Pádraig Brady wrote:
On 04/03/2024 00:44, Paul Eggert wrote:
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to
On 04/03/2024 15:44, Daniel Hofstetter wrote:
Hi,
When specifying an invalid length value followed by a valid length
value I get the following error:
$ printf "hello" | cksum --algo=blake2b --length=12 --length=8
cksum: invalid length: ‘12’
cksum: length is not a multiple of 8
However, if the
On 04/03/2024 00:44, Paul Eggert wrote:
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to A. However, this is not true for 'mv -x A
B'
Hi,
When specifying an invalid length value followed by a valid length
value I get the following error:
$ printf "hello" | cksum --algo=blake2b --length=12 --length=8
cksum: invalid length: ‘12’
cksum: length is not a multiple of 8
However, if the invalid length value is a multiple of 8 and
On 3/4/24 03:10, Paul Eggert wrote:
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
Le ven. 1 mars 2024 à 20:30, Pádraig Brady a écrit :
> On 01/03/2024 15:33, lacsaP Patatetom wrote:
> > hi,
> >
> > I did a few tests with tr and I'm surprised by the results...
> >
> > $ echo éèçà
> > éèçà
> >
> > these characters are encoded in utf-8 on 2 bytes :
> >
> > $ echo éèçà | xxd
> >
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
hardware. For example, if you're using
I don't know whether the problem I've found is with cp or with cmp, so
I don't know whether to address this report to coreutils or diffutils.
If you think I've guessed wrong, please tell me so.
I am trying to make a backup copy of a very large (40 Gigabyte) data
file - yes, I have plenty
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to A. However, this is not true for 'mv -x A
B' when B is a directory; it renames B
On 01/03/2024 15:33, lacsaP Patatetom wrote:
hi,
I did a few tests with tr and I'm surprised by the results...
$ echo éèçà
éèçà
these characters are encoded in utf-8 on 2 bytes :
$ echo éèçà | xxd
: c3a9 c3a8 c3a7 c3a0 0a .
now I use tr to remove
hi,
I did a few tests with tr and I'm surprised by the results...
$ echo éèçà
éèçà
these characters are encoded in utf-8 on 2 bytes :
$ echo éèçà | xxd
: c3a9 c3a8 c3a7 c3a0 0a .
now I use tr to remove non-printable characters :
$ echo éèçà | tr -cd
101 - 200 of 29374 matches
Mail list logo
