bug#34860: Probing broken symlinks always involves errors

bug#34860: Probing broken symlinks always involves errors

[Tim Gesthuizen]

Hi,
I wrote a little application that tries to probe whether a symlink
exists. The `stat` function has an undocumented optional parameter that
lets stat return #f when the file does not exist. With this argument one
can probe for any files excluding broken symlinks.
lstat does not offer this argument. Therefore I needed to use
guard-expressions around lstat to probe for broken symlinks.

So probing broken symlinks relies on errors in the control flow and is
not straight forward. Maybe we should add the optional argument that
`stat` has and document the arguments for both commands.

I am using guile 2.2.4.

Tim.

bug#34860: Probing broken symlinks always involves errors

[Mark H Weaver]

Hi Tim,

Tim Gesthuizen <tim.gesthuizen@yahoo.de> writes:

> I wrote a little application that tries to probe whether a symlink
> exists. The `stat` function has an undocumented optional parameter that
> lets stat return #f when the file does not exist. With this argument one
> can probe for any files excluding broken symlinks.
> lstat does not offer this argument. Therefore I needed to use
> guard-expressions around lstat to probe for broken symlinks.
>
> So probing broken symlinks relies on errors in the control flow and is
> not straight forward.

I would suggest using 'false-if-exception', which is documented in the
manual:

  (false-if-exception (lstat file-name))

That seems fairly straightforward and readable, no?

I'm not sure that errors in the control flow is necessarily something
that we need to avoid in cases like this.  It's true that there's some
minor expense involved in handling the exception, but I suspect it's
lost in the noise compared with the expense of the 'lstat' system call
itself.

Do you see a practical problem with this approach?

> Maybe we should add the optional argument that `stat` has and document
> the arguments for both commands.

I'm not strongly opposed to the idea, but it raises the question of what
to do with the corresponding C API function 'scm_lstat'.  We certainly
can't change the number of arguments to 'scm_lstat' in the 2.2.x series,
because that would break ABI compatibility.  We could change it in the
next release series, but that would require source-level changes in any
code that uses 'scm_lstat'.

Alternatively, we could keep 'scm_lstat' unchanged, and add a new
internal C function with the optional argument, bound to Scheme 'lstat'.

Anyway, I'm inclined to simply suggest using 'false-if-exception'.

What do you think?

Regardless, thanks for bringing my attention to the fact that 'scm_stat'
is incorrectly documented in the manual.  It asserts that there's only
one argument to that function, but in fact there are now two.  That's
definitely a bug.

     Regards,
       Mark

bug#34860: Probing broken symlinks always involves errors

[Tim Gesthuizen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Mark,

Mark H Weaver writes:
> Anyway, I'm inclined to simply suggest using 'false-if-exception'.
>
> What do you think?

I'm fine with this solution. My point was more about lowering the entry
barrier for beginners than performance.
If the change breaks ABI it is probably just not worth it.

- From my point of view we can close the ticket unless you want to keep it
open until the documentation for stat is fixed.

Tim.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEKUiC5+8BRKEri5fa0uWPaa77GdUFAlyvgdUACgkQ0uWPaa77
GdWvVQf/QdJ6Mze6jdx3qeFNjcq0hJCdkjykjWQal2m2eFNan+9RgrWUo/oGmJxq
9kVrckRE8lSH0Lh0jy5vhVtf4kBLcEKMB3oHBg7SM/w10nYsqkeZx+hV+MQkKQ3O
FomSddVDwa1R2aCHOJ55anHehvY5ICe2iQnASRPV4S/1h29b4cqg6W8OoKAiB2XR
GP7xfJ2s9y1IUm/0zSaAwpzr+CXcsplZVDgKcERo46/lfovFVsynhFJqNuU6ulBF
QJZAZyohH4SYiPQ21zq4r95WAr1UUfm8awJJuv5zgWx7wTcipUomXyINdnV6jEdT
bUGnNNOqpmhzzYuP0j+lI3yRqYb2/g==
=JSqx
-----END PGP SIGNATURE-----

bug#34860: Probing broken symlinks always involves errors

[Ludovic Courtès]

Hi Tim,

Tim Gesthuizen <tim.gesthuizen@yahoo.de> skribis:

> Mark H Weaver writes:
>> Anyway, I'm inclined to simply suggest using 'false-if-exception'.
>>
>> What do you think?
>
> I'm fine with this solution. My point was more about lowering the entry
> barrier for beginners than performance.
> If the change breaks ABI it is probably just not worth it.
>
> From my point of view we can close the ticket unless you want to keep it
> open until the documentation for stat is fixed.

Commit 63f54a7bc6adbc0f1b397872fb7eb96e84967ff1 updates the manual to
document the optional parameter of ‘stat’.

I think we can close the bug now.  :-)

Thanks,
Ludo’.