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.

Reply via email to