bug#32198: tail -f -F unexpected behavior
tags 32198 notabug close 32198 stop Hello, It seems your message has not been replied to in a long while. Sorry about that. On 2018-07-18 8:24 a.m., Matthew Guidry wrote: I was doing some experimentation with nano v2.9.3 and tail, watching the output of tail after saving in nano and encountered some strange behavior. This is not a bug at all (not in tail nor in nano). It is the result of updating a file in-place (i.e. changing existing bytes) which 'tail' already consumed. I had two terminals open side by side; one with nano and one with tail. I opened a file called test.txt in nano and saved with ^w in the first terminal. I went to the second terminal and ran tail -f test.txt to watch the file. I went back to the nano terminal and returned twice and saved. The tail terminal reports this change properly. With the file still open in nano, I write any number of characters and save. The tail terminal reports this change But skips the first character. To better see what happens, open a third terminal, and run the following command (after initially saving the file): watch -n1 od -tc test.txt Which will show the content of the file, updated once a second. I will use a similar but slightly different flow: 1. When you first save (in nano) the file, it is empty. The "od" terminal will show: 000 2. Type "12345" (don't press ENTER), and save (ctrl-O). The "od" terminal will show: 000 1 2 3 4 5 \n 006 The "tail" terminal will show: 12345 AND the cursor in the "tail" terminal will go to the next line (as there is a newline in the file). 3. Still in nano, on the same line, type "67890" (don't press ENTER), and save (CTRL-O). The "od" terminal will show: 000 1 2 3 4 5 6 7 8 9 0 \n 011 The "tail" terminal will show: 12345 7890 Here, the "6" character was not displayed by "tail". The reason is that that character in offset 6 of the file used to be a newline, and "tail" already consumed it. When the line was changed, nano went back and changed existing data in the file (or re-wrote the file completely - not sure about the implementation). "tail" has no way to detect that or "go back" in the file. This is a carefully constructed example, where the data change is small enough so that that "tail" almost doesn't notice it. If you make larger changes, or delete some parts of the file, nano will rewrite the file completely and "tail" will issue a warning such as: tail: test.txt: file truncated and then re-read the file. As such I'm closing this as "not a bug", but discussion can continue by replying to this thread. regards, - assaf
bug#8960: stdbuf on bi-arch systems
Hi Assaf, > >> The program 'stdbuf' on bi-arch x86 / x86_64 systems cannot work on all > >> kinds > >> of programs. > [...] > >> I would like to have a single binary that works on both x86 and x86_64 > >> programs. > [...] > > if stdbuf sets both LD_PRELOAD_32 and LD_PRELOAD_64 to the > > appropriate libstdbuf.so, it should just work. > > It's been more than 7 years since last comments/progress on this issue. > Is it still relevant / needed ? Yes, it is still relevant: * Bi-arch systems are still frequent. Large packages are still often provided as 32-bit binaries, from some vendors. * The behaviour of stdbuf in coreutils-8.30 is still the same: $ /arch/x86-linux/gnu/bin/stdbuf -o 0 /bin/pwd ERROR: ld.so: object '/arch/x86-linux/gnu/libexec/coreutils/libstdbuf.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. /home/bruno $ /arch/x86_64-linux/gnu/bin/stdbuf -o 0 /arch/x86-linux/gnu/bin/pwd ERROR: ld.so: object '/arch/x86_64-linux/gnu/libexec/coreutils/libstdbuf.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. /home/bruno * The distributor (Ubuntu 16.04 in my case) has not fixed the problem either: $ /usr/bin/stdbuf --version stdbuf (GNU coreutils) 8.25 ... $ /usr/bin/stdbuf -o 0 /arch/x86-linux/gnu/bin/pwd ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/coreutils/libstdbuf.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. /home/bruno Bruno
bug#33646: [PATCH] doc: improve wording of the --kibibytes option description
On Friday, January 18, 2019 8:26:18 AM CET Assaf Gordon wrote:
> Hello,
>
> On 2018-12-06 6:32 a.m., Kamil Dudka wrote:
> > Bug: https://bugzilla.redhat.com/1527391
> > ---
> >
> > doc/coreutils.texi | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> > index f8339d73f..e93fe71a0 100644
> > --- a/doc/coreutils.texi
> > +++ b/doc/coreutils.texi
> > @@ -7975,9 +7975,11 @@ Append @samp{*} for executable regular files,
> > otherwise behave as for>
> > @opindex --kibibytes
> > Set the default block size to its normal value of 1024 bytes,
> > overriding any contrary specification in environment variables
> >
> > -(@pxref{Block size}). This option is in turn overridden by the
> > -@option{--block-size}, @option{-h} or @option{--human-readable}, and
> > -@option{--si} options.
> > +(@pxref{Block size}). If @option{--block-size}, @option{-h},
> > +@option{--human-readable}, or @option{--si} options are used,
> > +they take precedence over @option{-k} or @option{--kibibytes}
> > +even if @option{-k} or @option{--kibibytes} is placed after
> > +the other options.
> >
> > The @option{-k} or @option{--kibibytes} option affects the
> > per-directory block count written by the @option{-l} and similar
>
> I'm ok with this improvement - if there are no comments
> I'll push in the next few days.
>
> -assaf
Sounds good. Thank you for taking care of it!
Kamil
bug#32455: cp gets confused by symlinks to parent directory
tags 32455 notabug
close 32455
stop
Hello,
It seems your message has not been replied to in a long while.
Sorry about that.
On 2018-08-16 8:47 a.m., Mike Crowe wrote:
If cp is passed the -d option and told to copy a symlink to the directory
containing the symlink then it ends up removing the target directory so it
is unable to create the symlink.
If my understanding is correct, the "-d" flag is not relevant to the
issue. The problem is that "self" is a symlink to a directory:
Reproduction script:
--8<--
#!/bin/sh
set -x
rm -rf temp
mkdir -p temp/src temp/dest
ln -s . temp/src/self
# This one works
cp -vd temp/src/self temp/dest/self
This works because "temp/dest/self" does not exist.
In this case, "temp/dest" is taken as the destination directory,
and "self" is taken as the name of the file/dir/symlink to create.
That is, you could run "cp -vd temp/src/self temp/dest/foobar"
to create "foobar" as a copy of "self".
# This one fails
cp -vd temp/src/self temp/dest/self
Here, "temp/dest/self" already exists, and it is a symlink to
a directory.
Meaning, the request is: copy "temp/src/self" into the directory
"temp/dest/self/" (and create "temp/dest/self/self").
This would have gone well, except that because "self" is a symlink
to ".", it can be resolved indefinitely:
$ file temp/dest/self
temp/dest/self: symbolic link to .
$ file temp/dest/self/self/self/self/self/self
temp/dest/self/self/self/self/self/self: symbolic link to .
$ file temp/dest/self/self/self/self/self/self/self
temp/dest/self/self/self/self/self/self/self: symbolic link to .
"cp" first removes "temp/dest/self/self" (which is valid),
but then, "temp/dest/self" is gone (since it is the same file path after
resolving it).
Hence, "cp" fails by saying "no such directory" on "temp/dest/self/self".
When this step is done, "temp/dest/self" does not exist,
and so:
# This one works again
cp -vd temp/src/self temp/dest/self
This works as before.
You can observe what happens on the kernel level
by adding "strace -e trace=file" before the "cp" commands,
this might help in deeper understanding.
To illustrate this differently:
When creating regular directories and files,
then deleting the innermost files, it is naively expected
that the parent directories still exist:
mkdir -p a/b/c/d
touch a/b/c/d/e
rm a/b/c/d/e
That is, a normal program can call "dirname("a/b/c/d/e")"
to get the parent directory of "e", and expect it to still
exist even after "e" is deleted.
But with your case:
$ mkdir a
$ ln -s . a/self
$ rm a/self/self/self/self/self/self
All the "apparent" parent directories ("self/self/self/self/self")
are gone!
Expected behaviour:
There should be no error message emitted by the second invocation of cp,
and the target directory should be in the same state as it is after the
first or third attempts to copy the symlink.
Not exactly.
What you want is for the DEST parameter of "cp" to always be a file,
never to be considered a directory, i.e. "temp/dest/self"
should always be interpreted as file "self" in directory "temp/dest",
never as directory "temp/dest/self".
Luckily, there is already an option for that:
-T, --no-target-directory
treat DEST as a normal file
With "-T", repeated commands work as you expected:
$ mkdir -p temp/src temp/dest
$ ln -s . temp/src/self
$ cp -vdT temp/src/self temp/dest/self
'temp/src/self' -> 'temp/dest/self'
$ cp -vdT temp/src/self temp/dest/self
removed 'temp/dest/self'
'temp/src/self' -> 'temp/dest/self'
$ cp -vdT temp/src/self temp/dest/self
removed 'temp/dest/self'
'temp/src/self' -> 'temp/dest/self'
$ cp -vdT temp/src/self temp/dest/self
removed 'temp/dest/self'
'temp/src/self' -> 'temp/dest/self'
[... ad infinitum ...]
I hope this addresses the issue,
I'm closing this as "not a bug", but discussion can continue by replying
to this thread.
regards,
- assaf
bug#34110: feature request: dual-column du output, showing "real" and "on-disk" sizes (and about that "apparent-size" concept)
Hello, On 2019-01-18 2:56 a.m., René J.V. Bertin wrote: the code isn't the most welcoming to dive into I've ever seen ;) Two online resources that might help in exploring the code: http://www.maizure.org/projects/decoded-gnu-coreutils/ https://opengrok.housegordon.com/source/xref/coreutils/ regards, - assaf
bug#34110: feature request: dual-column du output, showing "real" and "on-disk" sizes (and about that "apparent-size" concept)
On Thursday January 17 2019 23:43:39 Assaf Gordon wrote: >The parameter name "--apparent-size" is not likely to be changed. I was thinking of making it an alias for a more aptly named parameter (long) before (possibly) phasing out the current name. >It has been named so for about 16 years (since 'fileutils 4.5.8' A lot has happened on the filesystem front since that time. Just saying :) >Concrete patches are welcomed. I bet. We'll see who finds the time for that (the code isn't the most welcoming to dive into I've ever seen ;)) Cheers, R.
bug#8960: stdbuf on bi-arch systems
severity 8960 wishlist stop (triaging old bugs) Hello, On 2011-07-04 10:15 a.m., Pádraig Brady wrote: On 29/06/11 21:47, Bruno Haible wrote: The program 'stdbuf' on bi-arch x86 / x86_64 systems cannot work on all kinds of programs. [...] I would like to have a single binary that works on both x86 and x86_64 programs. [...] if stdbuf sets both LD_PRELOAD_32 and LD_PRELOAD_64 to the appropriate libstdbuf.so, it should just work. It's been more than 7 years since last comments/progress on this issue. Is it still relevant / needed ? If no one replies, I'll close it as "wontfix" in a few days. regards, - assaf
bug#12339: Gnu rm, changed only recently (4-5 years), and didn't follow letter of posix...(statement follows)
close 12339 stop (triaging old bugs) Hello, This long and winding thread covers several topics relating to rm(1), historical unix and POSIX compatibility (and a bugfix or two in the mix). An enlightening read for those interested... ( https://bugs.gnu.org/12339 ) But the bottom line is: rm -rf . will not delete the content of the current directory (while keeping the directory itself) and that is not likely to change. Two suggested alternatives: find . -delete rm -rf * .[!.] .??* As such, and with no more comments in 6 years, I'm closing this bug. PLEASE do not reply to this thread. If there are other relevant issues (that have not been discussed elsewhere, and have not been previously rejected), please start a new thread by emailing coreut...@gnu.org . regards, - assaf
bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...
retitle 12400 rmdir: add --one-file-system option
severity 12400 wishlist
tags 12400 wontfix
stop
(triaging old bugs)
Hello,
On 2012-09-09 11:22 p.m., Bob Proulx wrote:
Linda Walsh wrote:
If you are going to only provide 1 mode of functionality, it should
be to only rmdir dirs on the same file system as the starting args.
[...]
But rmdir only removes the directories you tell it to remove.
[...]
If you want a recursive option why not use 'rm -rf'?
There is always 'find' with the -delete option. But regardless there
has been the find -exec option.
find /some/path -type d -delete
find /some/path -depth -type d -exec rmdir {} +
With no further comments in 6 years, I'm closing this
request.
regards,
- assaf
bug#33211: coreutils.mo is in both LC_TIME and LC_MESSAGES folders
tags 33211 notabug close 33211 stop Hell0, On 2018-10-30 3:33 p.m., scootergrisen wrote: I wonder if its a mistake that in Fedora i can see coreutils.mo in both: /usr/share/locale/*/LC_TIME /usr/share/locale/*/LC_MESSAGES They seem to be identical. This is not a mistake (nor a bug). Not only they are identical, one is a symlink to the other: $ cd /usr/local/share/locale/ca $ ls -log LC_*/coreutils.mo -rw-r--r-- 1 379478 Dec 27 22:47 LC_MESSAGES/coreutils.mo lrwxrwxrwx 1 27 Dec 27 22:47 LC_TIME/coreutils.mo -> ../LC_MESSAGES/coreutils.mo coreutils.mo is the only file i see in the /usr/share/locale/*/LC_TIME folder. Most programs that use gettext (https://www.gnu.org/software/gettext/) are concerned with user visible messages, hence most of the translation only use LC_MESSAGES directory, and there's no need for other files. Few coreutils programs (e.g. date, sort) do care about translation of time-related strings (e.g. days / month names). That's why coreutils also uses LC_TIME. One can ask for the date/time to use one local, and messages to use another: $ export LC_TIME=ru_RU.UTF-8 $ export LANGUAGE=ja_JP.UTF-8 $ date Пт янв 18 01:06:10 MST 2019 $ date -d ABCD date: `ABCD' は無効な日付です Should the /usr/share/locale/*/LC_TIME/coreutils.mo files be removed so there is only the /usr/share/locale/*/LC_MESSAGES/coreutils.mo files? No, Both should exist, otherwise setting LC_TIME won't work. Technically, the translated strings for both messages and time are stored in the same file - that's why when coreutils is installed, one is a symlink to the other. Even more technically, when building from source, the file "bootstrap.conf" contains the following: # Other locale categories that need message catalogs. EXTRA_LOCALE_CATEGORIES=LC_TIME The directory "./po" is populated with available translation (e.g. "ru.po" and "ja.po"). During the build, the ".po" files are compiled into binary ".gmo" files. During installation, the files are copied/symlinked: $ make install [...] make[2]: Entering directory '/home/gordon/projects/coreutils/po' installing af.gmo as /usr/local/share/locale/af/LC_MESSAGES/coreutils.mo installing af.gmo link as /usr/local/share/locale/af/LC_TIME/coreutils.mo installing be.gmo as /usr/local/share/locale/be/LC_MESSAGES/coreutils.mo installing be.gmo link as /usr/local/share/locale/be/LC_TIME/coreutils.mo [...] Hope this addresses the issue. I'm closing this as "not a bug", but discussion can continue by replying to this thread. regards, - assaf
