| 1 |
On 11/30/2016 11:45 AM, Mike Gilbert wrote: |
| 2 |
> On Wed, Nov 30, 2016 at 11:28 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 3 |
>> On 11/26/2016 12:47 PM, Mike Gilbert wrote: |
| 4 |
>>> The values get clobbered immediately afterward, so why bother? |
| 5 |
>>> ... |
| 6 |
>>> qeinfo "Determining the location of the kernel source code" |
| 7 |
>>> - [ -h "${KERNEL_DIR}" ] && KV_DIR="$(readlink -f ${KERNEL_DIR})" |
| 8 |
>>> [ -d "${KERNEL_DIR}" ] && KV_DIR="${KERNEL_DIR}" |
| 9 |
>>> |
| 10 |
>> |
| 11 |
>> This changes the behavior if $KERNEL_DIR is a symbolic link to a |
| 12 |
>> nonexistent directory, doesn't it? |
| 13 |
> |
| 14 |
> Yes, I suppose it does. Do you anticipate that will cause a problem? |
| 15 |
> |
| 16 |
|
| 17 |
*shrug* |
| 18 |
|
| 19 |
There's a bug there, but who knows what the code was supposed to do. The |
| 20 |
docs say that KV_DIR is |
| 21 |
|
| 22 |
...a string containing the kernel source directory, will be null if |
| 23 |
KERNEL_DIR is invalid |
| 24 |
|
| 25 |
To me, that makes the "readlink" line the bug, because KV_DIR will be |
| 26 |
set even if KERNEL_DIR points nowhere. But then why is the readlink |
| 27 |
there? Should KERNEL_DIR support symlinks? (Probably, yes.) If so, the |
| 28 |
second test should be something like |
| 29 |
|
| 30 |
[ ! -d "${KV_DIR}" ] && KV_DIR="" |
| 31 |
|
| 32 |
to undo the previous line when KERNEL_DIR didn't lead anywhere. A better |
| 33 |
fix would avoid setting KV_DIR entirely in that case. |
Archives