bug#24495: tail -F does not terminate when running out of names to watch

[Pádraig Brady]

On 28/09/16 22:37, Bernhard Voelker wrote:
> On 09/28/2016 03:27 PM, Pádraig Brady wrote:
>> The attached patch how has the preferred behavior option 2
>> both with and without inotify.
> 
> Great, this looks good to me.
> +1

Thanks for the reviews.
Pushed at:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.25-73-gf04daf5

Marking this as done

bug#24495: tail -F does not terminate when running out of names to watch

[Bernhard Voelker]

On 09/28/2016 03:27 PM, Pádraig Brady wrote:
> The attached patch how has the preferred behavior option 2
> both with and without inotify.

Great, this looks good to me.
+1

Thanks & have a nice day,
Berny

bug#24561: Unmathematical bc exponentiation behavior

[Bernhard Voelker]

tag 24561 notabug
close 24561
stop


On 09/28/2016 05:48 PM, Martens, Tobias wrote:
> echo "-(1)^2" | bc
> 1

Andreas already gave the answer: operator precedence (see 'man bc').
Besides, bc(1) is not part of GNU coreutils, and a better address for
such a report would have been "bug...@gnu.org".
Therefore, I'm marking this as 'not a bug' here, closing the issue.

Have a nice day,
Berny

bug#23024: ls output quoting (when using --dired switch)

[Pádraig Brady]

On 16/03/16 17:07, Pádraig Brady wrote:
> On 15/03/16 23:35, Daniel Lopez wrote:
>> Hi,
>>
>> The recent change to the default way that ls renders filenames with
>> spaces in (now surrounding them in single quotes) is also happening in
>> the presence of this switch:
>>
>> -D, --diredgenerate output designed for Emacs' dired mode
>>
>> and it's correspondingly breaking Emacs' dired mode in some
>> circumstances. Specifically, it's affecting me when I use dired in Emacs
>> to browse files on a remote machine through Emacs' 'Tramp' feature. The
>> spaced/quoted files and directories can't be opened or navigated into.
>>
>> Test case:
>> - Start Emacs (I'm using the current stable version 24.5.1)
>> - Find file (C-x C-f) and enter "/ssh:localhost:" (since I'm using
>> localhost as an example, you'll need to have a local SSH server running)
>> - Notice that files or directories with spaces in the name are
>> surrounded in quotes, and can't be opened (by putting the cursor on them
>> and pressing return)
>>
>> Whatever one thinks of the default change in general (I disapprove,
>> myself; I find the intermittently-appearing quotes disturbing the
>> alignment in an "ls -l" and disrupting my flow as a human reader),
>> perhaps it should be done in a way that does not disturb other use cases
>> that ls also explicitly claims to support.
> 
> Right, we shouldn't mess with quoting in --dired mode.
> I'll fix it up shortly.

On further analysis I see that --dired mode already distinguishes
the quoting-style in its output.  Also we had already documented
that --dired should specify a --quoting-style to get consistent output.
Also this looks to have been fixed already in emacs:
https://github.com/emacs-mirror/emacs/commit/e4adb6

That handles all cases as well as users having QUOTING_STYLE
set in their environment with versions of ls prior to 8.24.

Therefore I'm inclined to leave this behavior as is.

thanks,
Pádraig

bug#24561: Unmathematical bc exponentiation behavior

[Andreas Schwab]

On Sep 28 2016, "Martens, Tobias"  wrote:

> echo "-(1)^2" | bc
> 1
>
> I would have expected -1. This behavior is unmathematical and very confusing, 
> because otherwise bc acts quite logic.
> Not sure if it is mandated by POSIX

Unary - has higher precedence than ^, thus it is parsed as (-(1))^2.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#24561: Unmathematical bc exponentiation behavior

[Martens, Tobias]

Hey,

echo "-(1)^2" | bc
1

I would have expected -1. This behavior is unmathematical and very confusing, 
because otherwise bc acts quite logic.
Not sure if it is mandated by POSIX, atleast I could not find it to be in the 
section of exponentiation operator. Was this ever discussed?
Resolving "-(positive float)" to "(-1)*(positive float)" for intern calculation 
seems more appropriate to me and would give the desired results.

bug#24495: tail -F does not terminate when running out of names to watch

[Pádraig Brady]

On 27/09/16 21:16, Bernhard Voelker wrote:
> On 09/21/2016 08:15 PM, Pádraig Brady wrote:
>> We can get expected behavior option 1 with the attached patch.
>> Note that's inconsistent with current inotify behavior which does
>> _not_ actually give up on the name, as can be seen when starting
>> with a (non existent) file:
>>
>> $ touch foo
>> $ tail -F foo&
>> [1] 13624
>> $ rm foo; mkdir foo
>> tail: ‘foo’ has become inaccessible: No such file or directory
>> tail: ‘foo’ has been replaced with an untailable file; giving up on this name
>> $ rmdir foo; echo foo > foo
>> tail: ‘foo’ has become inaccessible: No such file or directory
>> tail: ‘foo’ has appeared;  following new file
>> foo
>>
>> The attached patch also removes the "; giving up on this name"
>> message in the inotify case as that's not the case.
>>
>> Ideally we'd have expected behavior option 2
>> both with and without inotify.
>> I'll need to look a bit more as to why we have that
>> limitation without inotify.
> 
> The new behavior is nice, but it would really be better to have
> consistent behavior in inotify and polling mode.

Yes consistency would be nice. Looking at the polling behavior I see it was
not fundamental to the initial implementation and only changed later:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=FILEUTILS-4_0q-68-g54d12f7

The attached patch how has the preferred behavior option 2
both with and without inotify.

thanks,
Pádraig
From d76beda19d6c181915bb5323a19d965b899b20dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Wed, 21 Sep 2016 18:42:40 +0100
Subject: [PATCH] tail: -F now always processes initially untailable files

This was not the case when inotify was not available.

* src/tail.c (any_live_files): Simplify, since the IGNORE
flag is now only set when a file should be ignored indefinitely.
(recheck): Only output the "giving up on name" message
when that's actually the case.  Only set the IGNORE flag
when ignoring a file indefinitely.
(tail_file): Likewise.
* tests/tail-2/retry.sh: Add a test case.  Also run
all existing test cases with and without inotify.
NEWS: Mention the fix.
Fixes http://bugs.gnu.org/24495
---
 NEWS  |  5 +
 src/tail.c| 41 -
 tests/tail-2/retry.sh | 34 +-
 3 files changed, 54 insertions(+), 26 deletions(-)

diff --git a/NEWS b/NEWS
index beba774..c3554d0 100644
--- a/NEWS
+++ b/NEWS
@@ -42,6 +42,11 @@ GNU coreutils NEWS-*- outline -*-
   seq now immediately exits upon write errors.
   [This bug was present in "the beginning".]
 
+  tail -F now continues to process initially untailable files that are replaced
+  by a tailable file.  This was handled correctly when inotify was available,
+  and is now handled correctly in all cases.
+  [bug introduced in fileutils-4.0h]
+
   yes now handles short writes, rather than assuming all writes complete.
   [bug introduced in coreutils-8.24]
 
diff --git a/src/tail.c b/src/tail.c
index caa5407..c2982f5 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -956,8 +956,8 @@ recheck (struct File_spec *f, bool blocking)
   f->errnum = -1;
   f->ignore = true;
 
-  error (0, 0, _("%s has been replaced with a symbolic link. "
- "giving up on this name"), quoteaf (pretty_name (f)));
+  error (0, 0, _("%s has been replaced with a symbolic link"),
+ quoteaf (pretty_name (f)));
 }
   else if (fd == -1 || fstat (fd, _stats) < 0)
 {
@@ -986,17 +986,20 @@ recheck (struct File_spec *f, bool blocking)
 {
   ok = false;
   f->errnum = -1;
-  error (0, 0, _("%s has been replaced with an untailable file;\
- giving up on this name"),
- quoteaf (pretty_name (f)));
-  f->ignore = true;
+  f->tailable = false;
+  if (! (reopen_inaccessible_files && follow_mode == Follow_name))
+f->ignore = true;
+  if (was_tailable || prev_errnum != f->errnum)
+error (0, 0, _("%s has been replaced with an untailable file%s"),
+   quoteaf (pretty_name (f)),
+   f->ignore ? _("; giving up on this name") : "");
 }
   else if (!disable_inotify && fremote (fd, pretty_name (f)))
 {
   ok = false;
   f->errnum = -1;
-  error (0, 0, _("%s has been replaced with a remote file. "
- "giving up on this name"), quoteaf (pretty_name (f)));
+  error (0, 0, _("%s has been replaced with a remote file"),
+ quoteaf (pretty_name (f)));
   f->ignore = true;
   f->remote = true;
 }
@@ -1075,20 +1078,14 @@ any_live_files (const struct File_spec *f, size_t n_files)
 {
   size_t i;
 
-  if (reopen_inaccessible_files && follow_mode == Follow_name)
-return true;  /* continue following for -F option */
-
   for (i = 0; i < n_files; i++)
 {
   if (0 <= f[i].fd)
-{
-  return true;
-}
+