Page MenuHomeFreeBSD

sh(1): Remove unsubstantiated discourage use of -e
AcceptedPublic

Authored by michaelo on Fri, May 3, 8:01 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, May 8, 4:26 AM
Unknown Object (File)
Wed, May 8, 4:26 AM
Unknown Object (File)
Wed, May 8, 1:02 AM
Unknown Object (File)
Sun, May 5, 6:12 PM
Subscribers

Details

Summary

This partially reverts b14cfdf665bb8b7b2898a4ee5b073ab87f8ea3d0 and has
been discussed in D42719 to be unsubstantiated.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 57562
Build 54450: arc lint + arc unit

Event Timeline

The immediately preceding sentence about shell functions is an example of unexpected behaviour of set -e. The part "all commands of the function are considered to be tested as well" may result in code unexpectedly executing in the function and the function returning a different return status.

Many more examples can be found at https://mywiki.wooledge.org/BashFAQ/105 . Bash does not work exactly the same as our sh, but most of the problems are the same.

Bash's behaviour related to set -e has changed over the versions, but it has not succeeded in fixing the confusing parts. I don't believe it's possible to fix, and it is best to leave it unchanged so it is at least consistent.

set -e works reasonably well for scripts that are plain lists of commands with possible case, for, if, while and until, and only use && and || in conditions, which probably explains its use in make. However, even then, command substitution might lead to confusing results, for example because expr returns status 1 if the result is zero or the empty string, and the exit status from the inner command is passed through only in particular cases (for the last command substitution if there is no utility name).

A linting tool will probably be more effective (I've heard of ShellCheck, but I don't know whether it can catch missing error checks). With a linting tool, it matters less how beautiful the code looks but whether the tool can analyze it. Not enabling set -e makes the code easier to analyze, for example because functions don't behave differently depending on whether their return status is tested.

Another option is to use a better programming language. For a long time, there did not use to be one in the base system, but perhaps Lua is now a suitable option.

Manual pages are reference material and not a place for advocacy. Proper use of the feature, which seems to document its drawbacks (checked function call etc.), is a duty of the one writing a shell script. We don't have Python in base, so we can't recommend that.

This revision is now accepted and ready to land.Mon, May 6, 6:12 PM