Re: Feature Request kill and ps

[Mike Frysinger]

On Thursday 11 February 2010 17:36:55 Jan Girke wrote:
> I suggest kill eatin' names instead of numbers example:
> kill 'process name'

what's wrong with `killall` ?
-mike


signature.asc
Description: This is a digitally signed message part.

Re: Feature Request kill and ps

[Eric Blake]

According to Jan Girke on 2/11/2010 3:36 PM:
> Hi All
> 
> I had my thunderstorm cloud flying over my head again and managed to
> drop this mail.
> I suggest kill eatin' names instead of numbers example:
> kill 'process name'

And how exactly do you propose mapping 'process name' back to a particular
process, when there may well be more than one process with the same argv0
running at the same time?

> and ps sorting processes alphabetically example:
> ps -'free letter'

The unix philosophy is to do one thing and do it well.  What's wrong with
using 'ps | sort' to get your sorting?

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Changing man page format

[Chris F.A. Johnson]

Is it possible to change the formatting of man pages so that
they are not justified and have no hyphenation?

If so, which files have to be modified, and what would need to
be changed?


-- 
   Chris F.A. Johnson, 
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Feature Request kill and ps

[Jan Girke]

Hi All

I had my thunderstorm cloud flying over my head again and managed to
drop this mail.
I suggest kill eatin' names instead of numbers example:
kill 'process name'
and ps sorting processes alphabetically example:
ps -'free letter'
thanks, have a good time
and don't make myself bad weather,
will ya.

Re: strange automated path truncation with chmod

[jeff.liu]

dh-b...@online.de 写道:
> On Thu, 11 Feb 2010 21:54:19 +0800
> "jeff.liu"  wrote:
> 
>> could you supply more info?
> 
> am not shure what you want to hear? as written, there was no message on
> screen. after the mistake, i remounted the dvd-ram with -o rw and tried
> again (using arrow up and enter) and it worked.
the original mount info for your dvd-ram before remount operation.
and the related syscall lines which can be captured by strace.

"i mounted a dvd-ram and didn't recognize that it was mounted read-only
(don't know why, actually)."

you means the 'ro' flag did not shown from the mount output?

> 
>>> regards, 
>>> Dennis Heuer 
>>>
>>>
>> Regards,
>> -Jeff
>>
>>
>>
> 
> 
> regards,
> Dennis Heuer 
> 
> 

Re: Final point in new option of join

[Pádraig Brady]

On 11/02/10 21:29, Jim Meyering wrote:

Pádraig Brady wrote:
...

Actually there are a few more instance of that (due to me):

$ grep -E "  -.*  [A-Z]" *.c | grep -v "FILE"
base64.c:  -d, --decode  Decode data\n\
base64.c:  -i, --ignore-garbage  When decoding, ignore non-alphabet 
characters\n\
base64.c:  -w, --wrap=COLS   Wrap encoded lines after COLS character 
(default 76).\n\
stdbuf.c:  -i, --input=MODE   Adjust standard input stream buffering\n\
stdbuf.c:  -o, --output=MODE  Adjust standard output stream buffering\n\
stdbuf.c:  -e, --error=MODE   Adjust standard error stream buffering\n\
truncate.c:  -o, --io-blocksTreat SIZE as number of IO blocks instead 
of bytes\n\

It would be nice to have a syntax-check for this, though I
can't think of anything robust enough.  Hmm maybe if I grep man/*


Good idea.
Here's a first cut.
It would have to search only .c files.



This one currently ignores 2nd and subsequent lines of
multi-line descriptions.


That's why I didn't consider it robust enough :)



# This spots a capital on a short-only line (currently only one false positive)
git grep -E '^ {0,7}-\w( ?[^ ]+)?   *[A-Z][a-z]'

# This matches lines with a long option and optional preceding short option:
git grep -E '^   {0,7}(-\w( ?[^ ]+)?, )?--[^ ]*   *[A-Z][a-z]'


I had been trying this which seems to handle both:
grep -E " {2,6}-.*[^.]  [A-Z][a-z]" *.c

Searching man files allows us to take advantage of the extra
formatting to catch all cases (even though there currently any
extra found by this):
grep -E '^\\fB\\-' -A1 man/*.1 | grep '\.1.[A-Z][a-z]'

I'll play around with it some more and come up with something.

cheers,
Pádraig.

Re: Stty bug?

[Alan Curry]

Bob Proulx writes:
> 
> Alan Curry wrote:
> > I believe -iexten may be the problem. In your tty1 test, was iexten enabled?
> > Maybe a getty bug, it should be turning on iexten if it turns on iuclc.
> 
> I was able to recreate the original problem.  Reading Alan's response
> here I was surprised to see that adding iexten to iuclc did enable the
> desired behavior.  This would not have been required on traditional
> systems and its combination here isn't obvious to me.  There doesn't

Indeed, I believe iexten should be enabled by default, and my hazy memory
tells me it used to be. Turning it off is like saying "please punish me with
minimal POSIX tty capabilities"

> seem to be very much documentation available about iexten.  I am
> curious how you deduced that adding it would produce the desired
> behavior?

First, I saw -iexten in a report of tty misbehavior and got suspicious of it
right away since it's caused trouble for me before (lnext and werase are
useful!). Then I grepped to confirm it:

$ cd linux/drivers/char
$ grep IUCLC *.c
n_tty.c:if (I_IUCLC(tty) && L_IEXTEN(tty))
n_tty.c:if (I_ISTRIP(tty) || I_IUCLC(tty) || I_IGNCR(tty) ||

Bingo!

> 
> The documentation says:
> 
>   $ info coreutils 'stty invocation'

But at the next layer down, the documentation says:

$ man 3 tcsetattr
   IEXTEN Enable  implementation-defined  input processing.  This flag, as
  well as ICANON must be enabled for the special characters  EOL2,
  LNEXT, REPRINT, WERASE to be interpreted, and for the IUCLC flag
  to be effective.

Should the stty documentation try to describe every platform-dependent
combination of flags? That kind of manual can get bloated, and you end up
forcing everyone to read about the quirks of everyone else's platform,
instead of telling them how to use the one they're using.

> By my reading that doesn't give any hint that iexten is required for
> iuclc to function.  And indeed it isn't needed on a pty.  I don't

I tried it myself on a pty and couldn't reproduce your result.

> 
> I still think this is simply a Linux kernel tty driver bug.  I haven't
> looked at the code there yet though.

POSIX describes IEXTEN as "Enable extended input character processing." Does
that include the "processing" done by IUCLC, or does it just mean control
characters? You can argue that with the kernel mailing list if you want.

I still put most of the blame on getty. tty_std_termios (the kernel's
"default default" tty settings, which most drivers use to set the default
mode on a new tty) has IEXTEN enabled. getty is overriding the kernel's
default by setting all the flags to 0, and then turning on the ones it knows
about, and it doesn't know about IEXTEN.

This is what I'm seeing on Debian stable, where the "getty" is really agetty
from util-linux. I assume Ubuntu is the same.

-- 
Alan Curry

Re: Final point in new option of join

[Jim Meyering]

Pádraig Brady wrote:
...
> Actually there are a few more instance of that (due to me):
>
> $ grep -E "  -.*  [A-Z]" *.c | grep -v "FILE"
> base64.c:  -d, --decode  Decode data\n\
> base64.c:  -i, --ignore-garbage  When decoding, ignore non-alphabet 
> characters\n\
> base64.c:  -w, --wrap=COLS   Wrap encoded lines after COLS character 
> (default 76).\n\
> stdbuf.c:  -i, --input=MODE   Adjust standard input stream buffering\n\
> stdbuf.c:  -o, --output=MODE  Adjust standard output stream buffering\n\
> stdbuf.c:  -e, --error=MODE   Adjust standard error stream buffering\n\
> truncate.c:  -o, --io-blocksTreat SIZE as number of IO blocks instead 
> of bytes\n\
>
> It would be nice to have a syntax-check for this, though I
> can't think of anything robust enough.  Hmm maybe if I grep man/*

Good idea.
Here's a first cut.
It would have to search only .c files.
This one currently ignores 2nd and subsequent lines of
multi-line descriptions.

# This spots a capital on a short-only line (currently only one false positive)
git grep -E '^ {0,7}-\w( ?[^ ]+)?   *[A-Z][a-z]'

# This matches lines with a long option and optional preceding short option:
git grep -E '^   {0,7}(-\w( ?[^ ]+)?, )?--[^ ]*   *[A-Z][a-z]'

NEWS:--indicator-style=slash.  Use --file-type or
src/base64.c:  -d, --decode  Decode data\n\
src/base64.c:  -i, --ignore-garbage  When decoding, ignore non-alphabet 
characters\n\
src/base64.c:  -w, --wrap=COLS   Wrap encoded lines after COLS character 
(default 76).\n\
src/pr.c:   -D FORMAT, --date-format=FORMAT  Use FORMAT for the header date.
src/stdbuf.c:  -i, --input=MODE   Adjust standard input stream buffering\n\
src/stdbuf.c:  -o, --output=MODE  Adjust standard output stream buffering\n\
src/stdbuf.c:  -e, --error=MODE   Adjust standard error stream buffering\n\
src/stty.c:   -a, --allWrite all current settings to stdout in 
human-readable form.
src/stty.c:   -g, --save   Write all current settings to stdout in 
stty-readable form.
src/stty.c:   -F, --file   Open and use the specified device instead of stdin
src/truncate.c:  -o, --io-blocksTreat SIZE as number of IO blocks 
instead of bytes\n\

> I also noticed that there is inconsistent indenting for some --help output.
> I'm wary of changing that though as it might add too much churn for 
> translators?
> Look at ls --help for example where multiline comments for some options are 
> not indented.

It might not matter if xgettext's fuzzy matcher can compensate.
But then maybe it's not worth changing, either.

Re: Stty bug?

[Tom Lake]

--
From: "Bob Proulx" 
Sent: Thursday, February 11, 2010 12:32 PM
To: "Tom" ; 
Subject: Re: Stty bug?


Alan Curry wrote:

Tom writes:
> I'm using Ubuntu 9.10 (32-bit).
> I'm trying to use an ASR-33 Teletype (uppercase only)

Are you trying to write the best message this mailing list has ever aseen?
Because so far, it is.


Was that message to me?  If so and you're not being facetious, I'm flattered!


> As you can see, iuclc is set but no commands work

I believe -iexten may be the problem. In your tty1 test, was iexten enabled?
Maybe a getty bug, it should be turning on iexten if it turns on iuclc.


I never added iexten (sounds like a remedy for Erectile Dysfunction!)
since I had no clue that it has anything to do with iuclc.  I shall try it
tonight and report back.  If it works, I will nominate you for sainthood
and buy you a couple rounds of your favorite potable.  Of course, since you 
probably won't be able to get all the way up here (NYS near Canadian border)

to receive my offering, I'll just have to drink them for you.  Think of it as a
Mazel Tov Cocktail.

Later, dood!
Tom L 

Re: Stty bug?

[Bob Proulx]

Alan Curry wrote:
> Tom writes:
> > I'm using Ubuntu 9.10 (32-bit).
> > I'm trying to use an ASR-33 Teletype (uppercase only)
> 
> Are you trying to write the best message this mailing list has ever aseen?
> Because so far, it is.

I agree.  It puts my vt100 to shame. :-)

> > As you can see, iuclc is set but no commands work
> 
> I believe -iexten may be the problem. In your tty1 test, was iexten enabled?
> Maybe a getty bug, it should be turning on iexten if it turns on iuclc.

I was able to recreate the original problem.  Reading Alan's response
here I was surprised to see that adding iexten to iuclc did enable the
desired behavior.  This would not have been required on traditional
systems and its combination here isn't obvious to me.  There doesn't
seem to be very much documentation available about iexten.  I am
curious how you deduced that adding it would produce the desired
behavior?

The documentation says:

  $ info coreutils 'stty invocation'

`iexten'
   Enable non-POSIX special characters.  May be negated.

`iuclc'
   Translate uppercase characters to lowercase.  Non-POSIX.  May be
   negated.

The HP-UX 10.20 man page says the following and makes no mention of
iexten:

  If IUCLC is set, a received uppercase alphabetic character is
  translated into the corresponding lowercase character.

The SunOS man page says:

iexten (-iexten) Enable (disable) special control  characters
 not currently controlled by icanon, isig,
 ixon, or ixoff: VEOLZ, VSWTCH, VREPRINT,
 VDISCARD, VDSUSP, VWERASE, and VLNEXT.

By my reading that doesn't give any hint that iexten is required for
iuclc to function.  And indeed it isn't needed on a pty.  I don't
recall this having been needed on traditional Unix systems to enable
iuclc to function.  It isn't mentioned in the HP-UX documentation.

I still think this is simply a Linux kernel tty driver bug.  I haven't
looked at the code there yet though.

Bob

Re: Ubuntu stty

[Bob Proulx]

Alan Curry wrote:
> I already answered this the first time it was sent. The archive has my
> message:
>   http://lists.gnu.org/archive/html/bug-coreutils/2010-02/msg00020.html

Sorry.  I missed seeing that message when it went by.  But there it is
in the archive.  I had missed it.  Thanks for bringing it to my
attention.  I will make a response there.

> It didn't get through to Tom directly, though. His part of the Internet
> doesn't accept mail from my part. Someone in the middle (Bob?) could maybe
> tell him that he's missing out, by not being subscribed to the list and not
> checking the archive.

Of course bug reporters are not expected to be subscribed to the
mailing list.  Requiring that someone subscribe to a mailing list to
submit a bug report would be too much.  I see that you knew this and
did CC Tom as is the proper procedure.  All things being in working
order that is the right thing to do.  My message to Tom didn't bounce
so I will ping him directly.

Unfortunately it looks like you are sending email from a dynamically
allocated IP address block.  That creates problems.  If so then that
explains why your email was rejected.  My own site rejects all mail
from dynamic IP address ranges and I also wouldn't be able to receive
mail from you by this path.  You should relay through an email host
that is not in a dynamic IP range to avoid this problem.

Thanks,
Bob

Re: Final point in new option of join

[Pádraig Brady]

On 11/02/10 15:25, Eric Blake wrote:

Pádraig Brady  draigBrady.com>  writes:


I noticed a few more extraneious '.' in --help output



+++ b/src/base64.c
@@ -62,10 +62,9 @@ Base64 encode or decode FILE, or standard input, to

standard output.\n\

  \n"), program_name);
fputs (_("\
-w, --wrap=COLS   Wrap encoded lines after COLS character (default

76).\n\

-Use 0 to disable line wrapping.\n\
-\n\
-  -d, --decode  Decode data.\n\
-  -i, --ignore-garbage  When decoding, ignore non-alphabet characters.\n\
+  Use 0 to disable line wrapping\n\
+  -d, --decode  Decode data\n\
+  -i, --ignore-garbage  When decoding, ignore non-alphabet characters\n\


We should also patch these to start with lower case (that is:
   -d, --decodedecode data
rather than Decode data).


Actually there are a few more instance of that (due to me):

$ grep -E "  -.*  [A-Z]" *.c | grep -v "FILE"
base64.c:  -d, --decode  Decode data\n\
base64.c:  -i, --ignore-garbage  When decoding, ignore non-alphabet 
characters\n\
base64.c:  -w, --wrap=COLS   Wrap encoded lines after COLS character 
(default 76).\n\
stdbuf.c:  -i, --input=MODE   Adjust standard input stream buffering\n\
stdbuf.c:  -o, --output=MODE  Adjust standard output stream buffering\n\
stdbuf.c:  -e, --error=MODE   Adjust standard error stream buffering\n\
truncate.c:  -o, --io-blocksTreat SIZE as number of IO blocks instead 
of bytes\n\

It would be nice to have a syntax-check for this, though I
can't think of anything robust enough.  Hmm maybe if I grep man/*

I also noticed that there is inconsistent indenting for some --help output.
I'm wary of changing that though as it might add too much churn for translators?
Look at ls --help for example where multiline comments for some options are not 
indented.

cheers,
Pádraig.

Re: Final point in new option of join

[Eric Blake]

Pádraig Brady  draigBrady.com> writes:

> I noticed a few more extraneious '.' in --help output

> +++ b/src/base64.c
> @@ -62,10 +62,9 @@ Base64 encode or decode FILE, or standard input, to 
standard output.\n\
>  \n"), program_name);
>fputs (_("\
>-w, --wrap=COLS   Wrap encoded lines after COLS character (default 
76).\n\
> -Use 0 to disable line wrapping.\n\
> -\n\
> -  -d, --decode  Decode data.\n\
> -  -i, --ignore-garbage  When decoding, ignore non-alphabet characters.\n\
> +  Use 0 to disable line wrapping\n\
> +  -d, --decode  Decode data\n\
> +  -i, --ignore-garbage  When decoding, ignore non-alphabet characters\n\

We should also patch these to start with lower case (that is:
  -d, --decodedecode data
rather than Decode data).

-- 
Eric Blake

Re: strange automated path truncation with chmod

[dh-bugs]

On Thu, 11 Feb 2010 21:54:19 +0800
"jeff.liu"  wrote:

> 
> could you supply more info?

am not shure what you want to hear? as written, there was no message on
screen. after the mistake, i remounted the dvd-ram with -o rw and tried
again (using arrow up and enter) and it worked.

> 
> > regards, 
> > Dennis Heuer 
> > 
> > 
> Regards,
> -Jeff
> 
> 
> 


regards,
Dennis Heuer 

Re: strange automated path truncation with chmod

[jeff.liu]

dh-b...@online.de 写道:
> hello
> 
> i faced a very strange behaviour with the coreutils 8.4 chmod tool:
> 
> i mounted a dvd-ram and didn't recognize that it was mounted read-only
> (don't know why, actually). my first thought was that the access rights
> to the files were set improper. because the disk stores only archival
> stuff for everybody, and everybody means -I- on that system, i decided
> to set universal access rights (a quick thought without much
> investigation!) as root, i typed:
> 
> chmod -R 777 /media/*
> 
> interestingly, chmod didn't complain about the write-protection but,
> instead, the root filesystem got accessed for several seconds. i did a
> ctrl-c and found that chmod had actually done a:
> 
> chmod -R 777 /*
> 
> i can't explain this behaviour with common sense and consider it a bug.
> 
I can not reproduce this problem against the upstream chmod,

the scenario you mentioned is simulated as following,

j...@jeff-laptop:~$ mount
..
...
/dev/sda8 on /ocfs2 type ocfs2 (ro,heartbeat=none)
/dev/scd0 on /media/cdrom0 type udf (ro,nosuid,nodev,utf8,user=jeff)

j...@jeff-laptop:~$ sudo touch /ocfs2/b
touch: cannot touch `/ocfs2/b': Read-only file system
j...@jeff-laptop:~$ sudo chmod -R 777 /ocfs2
chmod: changing permissions of `/ocfs2': Read-only file system
chmod: changing permissions of `/ocfs2/lost+found': Read-only file system
chmod: changing permissions of `/ocfs2/a': Read-only file system

j...@jeff-laptop:~$ sudo chmod -R 777 /media/
chmod: changing permissions of `/media/cdrom0': Read-only file system
chmod: changing permissions of `/media/cdrom0/18.mov': Read-only file system
chmod: changing permissions of `/media/cdrom0/Masseuse.mp4': Read-only file 
system
chmod: changing permissions of `/media/cdrom0/Miindo2008.mkv': Read-only file 
system
chmod: changing permissions of `/media/cdrom0/SetupX64.avi': Read-only file 
system
chmod: changing permissions of `/media/cdrom0/WDK_6001_18001.iso': Read-only 
file system

could you supply more info?

> regards, 
> Dennis Heuer 
> 
> 
Regards,
-Jeff

Re: Unicode characters in tail and head

[Eric Blake]

According to richard.wos...@gmx.de on 2/11/2010 6:10 AM:
> Hello!
> 
> My question is the following:
> Will there be a '-m' or '--chars' option for tail and head? Because, when
> processing Unicode, the -c (--bytes) option isn't very useful.

Eventually, when someone contributes a maintainable patch that does not
bloat the code size and that is still efficient for unibyte locales, then
yes, we would like to support multibyte character processing in the
various text-based utilities.  Several vendors already have add-on patches
that add support along this front, but their implementations have not yet
qualified as worth merging upstream.  Patches are welcome.

> PS: I did some searching on this topic but I found no answer - if this was 
> asked and answered before, I appologize for wasting your time.

Yes, this has come up frequently on the list.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Unicode characters in tail and head

[Richard . Wossal]

Hello!

My question is the following:
Will there be a '-m' or '--chars' option for tail and head? Because, when
processing Unicode, the -c (--bytes) option isn't very useful.

Well, of course, it does what it should do - but I think it was designed with 
byte==char in mind (which is probably why it was called "-c").

Now I believe that tail/head should be able to process unicode, just like
wc does already - Unix (or Not Unix, for that matter) finally is all about 
text, not bytes, right?

With kind regards,

Richard Wossal

PS: I did some searching on this topic but I found no answer - if this was 
asked and answered before, I appologize for wasting your time.
-- 
Richard

Re: please fix the output of du -h

[Philip Rowlands]

On Thu, 11 Feb 2010, dh-b...@online.de wrote:


using -h with du on a directory tree can produce results several
gigabytes *below* the actual value. this is quite annoying (and just
plain wrong), especially when trying to burn a cd/dvd.


"du -h" doesn't do what you expect. Quoting the manual:

`-h'
`--human-readable'
 Append a size letter to each size, such as `M' for mebibytes.
 Powers of 1024 are used, not 1000; `M' stands for 1,048,576 bytes.
 This option is equivalent to `--block-size=human-readable'.  Use
 the `--si' option if you prefer powers of 1000.


Cheers,
Phil

please fix the output of du -h

[dh-bugs]

hello

using -h with du on a directory tree can produce results several
gigabytes *below* the actual value. this is quite annoying (and just
plain wrong), especially when trying to burn a cd/dvd.

regards, 
Dennis Heuer 

strange automated path truncation with chmod

[dh-bugs]

hello

i faced a very strange behaviour with the coreutils 8.4 chmod tool:

i mounted a dvd-ram and didn't recognize that it was mounted read-only
(don't know why, actually). my first thought was that the access rights
to the files were set improper. because the disk stores only archival
stuff for everybody, and everybody means -I- on that system, i decided
to set universal access rights (a quick thought without much
investigation!) as root, i typed:

chmod -R 777 /media/*

interestingly, chmod didn't complain about the write-protection but,
instead, the root filesystem got accessed for several seconds. i did a
ctrl-c and found that chmod had actually done a:

chmod -R 777 /*

i can't explain this behaviour with common sense and consider it a bug.

regards, 
Dennis Heuer 

Re: Bug#569020: coreutils: failure of install-C test on GNU/kFreeBSD

[Pádraig Brady]

On 11/02/10 10:29, Pádraig Brady wrote:

On 11/02/10 02:14, Michael Stone wrote:


FAIL: tail-2/inotify-hash-abuse2 (exit: 1)
==

tail: `f' has become inaccessible: No such file or directory
./tail-2/inotify-hash-abuse2: line 34: kill: (13733) - No such process
./tail-2/inotify-hash-abuse2: line 40: kill: (13733) - No such process


As far as I read the test, there will always be a race where f could be
temporarily unavailable between the mv and the touch.
I forget what it's supposed to be testing for, but to close that race, I
think

touch g
mv g f

would be better, no?


That's what we're explicitly trying to trigger.
`tail` should not exit in this case as -F is specified (--retry)


Perhaps if the box is heavily loaded it can't complete each
iteration of the loop within an average of 0.05s (in which
case the timeout would kick in), though I'd be surprised if your system
could only iterate < 20 times a second.

In any case, since the timeout is just here to ensure no tail's
are left running if the test is canceled, it's probably better
to explicitly clean up as in this patch. Could you try and reproduce with this?

--- a/tests/tail-2/inotify-hash-abuse2
+++ b/tests/tail-2/inotify-hash-abuse2
@@ -28,7 +28,8 @@ touch f || framework_failure

 debug='---disable-inotify -s .001'
 debug=
-timeout 10 tail $debug -F f & pid=$!
+tail $debug -F f & pid=$!
+cleanup_() { kill $pid; }

 for i in $(seq 200); do
   kill -0 $pid || break;

Re: Bug#569020: coreutils: failure of install-C test on GNU/kFreeBSD

[Pádraig Brady]

On 11/02/10 02:14, Michael Stone wrote:


FAIL: tail-2/inotify-hash-abuse2 (exit: 1)
==

tail: `f' has become inaccessible: No such file or directory
./tail-2/inotify-hash-abuse2: line 34: kill: (13733) - No such process
./tail-2/inotify-hash-abuse2: line 40: kill: (13733) - No such process


As far as I read the test, there will always be a race where f could be
temporarily unavailable between the mv and the touch.
I forget what it's supposed to be testing for, but to close that race, I
think

touch g
mv g f

would be better, no?


That's what we're explicitly trying to trigger.
`tail` should not exit in this case as -F is specified (--retry)

cheers,
Pádraig.