On 01/17/2014 07:23 AM, Bernhard Voelker wrote: > On 01/17/2014 05:03 AM, Pádraig Brady wrote: >> I'll push the attached soon to fix this. > > Thanks. > >> From 672b0b5f1023f7f433973edec7376fce330cb2a2 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?P=C3=A1draig=20Brady?= <p...@draigbrady.com> >> Date: Fri, 17 Jan 2014 03:54:29 +0000 >> Subject: [PATCH] ln: fix replacing symbolic links whose targets can't exist > >> diff --git a/tests/ln/sf-1.sh b/tests/ln/sf-1.sh >> index 3f4f8f1..ecf3aae 100755 >> --- a/tests/ln/sf-1.sh >> +++ b/tests/ln/sf-1.sh > >> +# Ensure we replace symlinks that don't or can't link to an existing target. >> +# coreutils-8.22 would fail to replace {ENOTDIR,ELOOP,ENAMETOOLONG}_link >> below. >> +name_max_plus1=$(expr $(stat -f -c %l .) + 1) >> +long_name=$(printf '%0*d' $name_max_plus1 0) > > Is there a chance that the above stat might fail? > In such a case, long_name would just be '0'.
I thought of that, but in that case the test will still pass. > Maybe adding this would do: > > test $name_max_plus1 -gt 1 || framework_failure_ Since the value is coming from external, a skip_ would be more appropriate to diagnose this edge case. I'll add that. thanks for the review! Pádraig.