Re: [PATCH] tests: document CMP/PRE/POST in unit test module
On April 1, 2013 at 11:47 PM Assaf Gordon assafgor...@gmail.com wrote:
Attached is a small patch to document CMP/PRE/POST in tests/Coreutils.pm.
No code changes.
Thanks for working on that.
Here are a few nits:
diff --git a/tests/Coreutils.pm b/tests/Coreutils.pm
index 71b1516..fd4408a 100644
--- a/tests/Coreutils.pm
+++ b/tests/Coreutils.pm
@@ -54,7 +54,7 @@ defined $ENV{DJDIR}
# I/O spec: a hash ref with the following properties
#
# - one key/value pair
-# - the key must be one of these strings: IN, OUT, ERR, AUX, CMP, EXIT
+# - the key must be one of these strings: IN, OUT, ERR, AUX, CMP, EXIT,
PRE,POST
# - the value must be a file spec
# {OUT = 'data'}put data in a temp file and compare it to stdout from
cmd
# {OUT = {'filename'=undef}} compare contents of existing filename to
s/PRE,POST/PRE, POST
due to the line length it may be worth adding a line break.
@@ -82,6 +82,12 @@ defined $ENV{DJDIR}
# {ENV_DEL = 'VAR'}
# Remove VAR from the environment just before running the corresponding
# command, and restore any value just afterwards.
+# {CMP = [ 'data',{'filename'=undef}}Compare the content of 'filename'
+# to 'data' (a string scalar). The program under test is expected to create
+# file 'filename'.
Close square brackets, and move blank character to after the comma:
-+# {CMP = [ 'data',{'filename'=undef}}Compare the content of 'filename'
++# {CMP = ['data', {'filename'=undef}]Compare the content of 'filename'
2 notes:
* According to the code, instead of a plain string, 'data' can also be a HASH.
* If the file name is '@AUX@', then it is replaced.
Furthermore, IN, AUX, and EXIT also do not seem to be documented yet.
Do you like to document these, too?
Have a nice day,
Berny
Re: [PATCH] tests: document CMP/PRE/POST in unit test module
Thanks for the quick reply.
Here's a better patch.
Bernhard Voelker wrote, On 04/02/2013 04:03 AM:
s/PRE,POST/PRE, POST
due to the line length it may be worth adding a line break.
Done. Also added IN_PIPE .
Close square brackets, and move blank character to after the comma:
Done.
2 notes:
* According to the code, instead of a plain string, 'data' can also be a HASH.
* If the file name is '@AUX@', then it is replaced.
I do not fully understand those uses, so I can't really explain them.
When are these useful?
Furthermore, IN, AUX, and EXIT also do not seem to be documented yet.
Do you like to document these, too?
I've added IN and IN_PIPE.
EXIT was already mentioned.
AUX - I do not know what it does...
-gordon
From 309fd6398558b6e85ae2b2fa1cee6b5e2f492dde Mon Sep 17 00:00:00 2001
From: Assaf Gordon assafgor...@gmail.com
Date: Mon, 1 Apr 2013 17:44:27 -0400
Subject: [PATCH] tests: document more test keys in unit test module
* tests/Coreutils.pm: document IN/IN_PIPE/CMP/PRE/POST keys.
---
tests/Coreutils.pm | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/tests/Coreutils.pm b/tests/Coreutils.pm
index 71b1516..661fce4 100644
--- a/tests/Coreutils.pm
+++ b/tests/Coreutils.pm
@@ -54,8 +54,12 @@ defined $ENV{DJDIR}
# I/O spec: a hash ref with the following properties
#
# - one key/value pair
-# - the key must be one of these strings: IN, OUT, ERR, AUX, CMP, EXIT
+# - the key must be one of these strings: IN, IN_PIPE, OUT, ERR, AUX, CMP,
+# EXIT, PRE, POST
# - the value must be a file spec
+# {IN = 'data'}Create file containing 'data'. The filename will be
+#appended as the last parameter on the command-line.
+# {IN_PIPE = 'data'} Send 'data' as input from stdin.
# {OUT = 'data'}put data in a temp file and compare it to stdout from cmd
# {OUT = {'filename'=undef}} compare contents of existing filename to
# stdout from cmd
@@ -82,6 +86,12 @@ defined $ENV{DJDIR}
# {ENV_DEL = 'VAR'}
# Remove VAR from the environment just before running the corresponding
# command, and restore any value just afterwards.
+# {CMP = ['data', {'filename'=undef}]}Compare the content of 'filename'
+# to 'data' (a string scalar). The program under test is expected to create
+# file 'filename'.
+# {PRE = sub{}} Execute sub() before running the test.
+# {POST = sub{}} Execute sub() after running the test.
+# If the PRE/POST sub calls die, the test will be marked as failed.
#
# There may be many input file specs. File names from the input specs
# are concatenated in order on the command line.
--
1.7.7.4
tail --retry not re-attempting to open file
tail --retry -f {FILE} or tail -f --retry {FILE} does continue to try to
open the file.
I just compiled 8.21 CoreUtils and found that the problem is still present.
I don't have any heavy programing experience. My 1st official report of any
bugs.
--
Noel Morrison (GMAIL)
Sr. System Administrator HP
noel.morri...@hp.com
bug#14108: Bug in dd
On April 1, 2013 at 6:58 AM Bob Proulx b...@proulx.com wrote: Haneef Mubarak wrote: dd doesn't have a quiet option, ie: dd --quiet Having a quiet option would allow for an easier use of piping with dd The dd manual documents this as status=none: Additional note: this has been added in coreutils-8.20, so unless building from source, the distribution used might not have this new option available yet. Have a nice day, Berny
bug#14116: [PATCH] ln: allow to overwrite relative symlink
I'm not sure to understand your first sentence. Resolving the last component is already the existing behavior, but maybe not the intended one. Anyway, I agree that the path should be resolved without its last component. I wrote a new patch for this. I hope that this one will not break anything. Rémy. 2013/4/2 Pádraig Brady p...@draigbrady.com On 04/01/2013 09:10 PM, Rémy Lefevre wrote: Rémy. 2013/4/1 Pádraig Brady p...@draigbrady.com mailto:p...@draigbrady.com On 04/01/2013 03:40 PM, Rémy Lefevre wrote: Overwriting relative symlink leads to undesirable behavior. Consider the following example: # Create some directories mkdir test mkdir test/folder1 mkdir test/folder2 #Create some files touch test/folder1/file1 touch test/folder1/file2 #Create a relative symlink in folder2 to file1 ln -sr test/folder1/file1 test/folder2/link #Check the link ls -l test/folder2/link # Correctly output a link to ../folder1/file1 #Overwrite the symlink to point to file2 ln -sfr test/folder1/file2 test/folder2/link #Check the link ls -l test/folder2/link # Wrongly output a link to file2 instead of ../folder1/file2 This undesirable behavior is due to a dereferencing of the target when the relative path is computed. Passing CAN_NOLINKS flag to canonicalize_filename_mode solves the problem. Doing that though breaks `ln -sr target1 target2 dir` where dir is a symlink. Also if /some/other/component of the path is a symlink, you probably want that resolved? You might even want the final component of the link name resolved in some cases. So perhaps the approach here is to only disable dereferencing when -n is set, and even then only for the last_component()? In other words, `ln -nsf ...` means update the specified link name no matter what it is. -n used only be significant when the link name was to a directory, but with -r it's also significant if linking outside its containing directory. I'll sort out a patch later. You are right. It breaks any path composed of link. Sorry for this bad patch. But could you provide me an example where the final component of the link should be resolved ? Does it make sense as the link will be overwritten? I must be missing something. Yes resolving the last component would be a departure from existing behavior. So it there is no need to conditionalize this on -n, and we just need to resolve the path without the last_component() and then tack that on. thanks, Pádraig. patch.diff Description: Binary data
