Yair Lenga [1970-01-01 00:00:00 +]:
>
> In my case, I have to bulk-move about 2500 files. This is part of a
> recurring sync job that has to mirror an existing hierarchy into a new
> hierarchy with different naming rules.
>
> It takes no time to create the mapping (even in bash script, case
The attached patchset addresses a minor issue with program behavior vs.
documentation of the df, du, and ls tools from coreutils-8.32, when using
the --si option.
It resurrects an issue that was brought up in 2014 [3] and eventually closed
in 2018 [4] with a wontfix (after minimal discussion in th
On 09 Sep 2020 17:46:36 -0700, L A Walsh wrote:
>
>
> On 9/8/2020 9:27 AM, Glenn Golden wrote:
> > The attached patchset addresses a minor issue with program behavior vs.
> > documentation of the df, du, and ls tools from coreutils-8.32, when using
> > the --si option
On Sat, Mar 27, 2021, at 13:24, L A Walsh wrote:
> On 2021/03/26 14:03, Peng Yu wrote:
> > Hi,
> >
> > When I try `ls -l dir1 dir2`, the order of dir1 and dir2 in the output
> > is not necessarily the same as the input. How to make it the same as
> > the input order? Thanks.
> >
> Use separate i
On Thu, Apr 15, 2021, at 08:41, Michael Stone wrote:
> On Thu, Apr 15, 2021 at 07:56:30AM -0500, Carl Edquist wrote:
> >Anyway, after some time if you find yourself wanting to use the feature a
> >lot but being bored to type --sort=width each time, maybe that will
> >provide more inclination to add
Florent Flament [October 21, 2021 07:14 -0600]:
>
> Pádraig Brady writes:
>
> > BTW the env var is POSIXLY_CORRECT, not STRICTLY_POSIX.
>
> Nice catch !
>
> > Anyway I don't think we should mention that in the man page anyway.
> > I'll push the attached later, which just says printf(1) is prefe
On Thu, Oct 28, 2021, at 15:59, Sworddragon wrote:
>
> Despite I'm not using Linux as main system anymore and wanted to avoid
> getting into too much work I found some time to do some tests as this issue
> bugs me just too much.
>
Suggestion as a possible workaround: Have a look at random(4) and
In coreutils 9.0:
$ /usr/bin/printf "%a\n" 0x1.1p-20
0x8.8p-23
$ c_printf 0x1.1p-20 # printf("%a\n", strtod(argv[1], NULL));
0x1.1p-20
Imo, this normalization inconsistency is worth addressing. What do you think?
There's nothing nume
Ping.
If this is the wrong list for this question, please point me to the right one.
(Btw, in my original post below, I neglected to mention the glibc version used
to prepare the C example. It was glibc 2.35.)
Thanks,
Glenn
On Sun, Apr 10, 2022, at 08:25, Glenn Golden wrote:
> In coreut
Not sure if this is a bug report, a feature request, or just a case of wrong
expectation on my part regarding the behavior of "tail --follow=name" when
the target is a special file (via a symlink). Perhaps what I'm trying to do
is unreasonable and shouldn't really be expected to work.
In any case
Pádraig Brady [2023-01-30 21:27:50 +]:
> On 30/01/2023 20:04, Glenn Golden wrote:
> > Not sure if this is a bug report, a feature request, or just a case of wrong
> > expectation on my part regarding the behavior of "tail --follow=name" when
> > the target i
Pádraig Brady [2023-01-31 21:47:43 +]:
> On 31/01/2023 19:48, Glenn Golden wrote:
> > Thanks, Pádraig.
> >
> > With the above patch (applied manually to coreutils 9.1 sources) the
> > 'illegal seek' no longer occurs, but it also doesn't follow t
Pádraig Brady [2023-02-01 20:37:47 +]:
>
> That was informative thanks.
>
> What I think is happening is that to support --follow=name tail(1) operates
> in non blocking mode so that it doesn't block when reading a file, and has
> the opportunity to recheck.
>
> Now it determines when a read
In an attempt to build coreutils with debug symbols, I was surprised to find
that this sequence:
$ git clone https://github.com/coreutils/coreutils
$ cd coreutils/
$ ./bootstrap
$ export CFLAGS=-g
$ ./configure --disable-silent-rules
$ make
resulted in the attached build failure. (The
Sam James [2023-02-03 19:49:45 +]:
>
> > On 3 Feb 2023, at 19:47, Glenn Golden wrote:
> >
> > In an attempt to build coreutils with debug symbols, I was surprised to find
> > that this sequence:
> >
> > $ git clone https://github.com/
Glenn Golden [2023-02-02 15:55:51 -0700]:
> Pádraig Brady [2023-02-01 20:37:47 +]:
> >
> > That was informative thanks.
> >
> > What I think is happening is that to support --follow=name tail(1) operates
> > in non blocking mode so that it doesn't bloc
Pádraig Brady [2023-02-05 19:13:15 +]:
>
> On 05/02/2023 16:56, Glenn Golden wrote:
> > Your two patches (the one mentioned above and the earlier one avoiding the
> > xlseek() on a non-regular file) do almost fix the problem, but not quite.
> > I added one additiona
On Sat, Jul 1, 2023, at 09:03, Bernhard Voelker wrote:
> On 7/1/23 14:12, Sergey Ponomarev wrote:
> > To rename a file a user need to use mv command and specify the DEST dir:
> >
> > mv /some/very/long/path/file /some/very/long/path/
> >
> > This makes it not so easy to use when typing
On Fri, Dec 20, 2024, at 07:51, Pádraig Brady wrote:
> * src/tail.c (tail forever): Exit with failure status
> like we do for the inotify case. This is also consistent
> with the failure exit if no file was accessible at tail startup.
> * tests/tail/follow-stdin.sh: Tweak due to earlier exit.
>
19 matches
Mail list logo
