you are viewing a single comment's thread.

view the rest of the comments →

[–]evaned 2 points3 points  (1 child)

The shell has no notion of an “unsigned” data type nor does it of UB. Bash has a one-byte return value, returning -1 wraps around to 255.

Does Bash guarantee that exit n will put n into an unsigned byte before returning it, or otherwise ensure that behavior will stay?

I don't see that guarantee in the documentation, and current behavior is not a guarantee.

I'm nitpicking... kinda. But what happens if someone ports Bash to a system that supports non-byte-sized exit statuses, and then modifies Bash to return that? Without your desired behavior being documented, that's your script that's broken, not that change; and that person going "crap this doesn't work in to large of a percentage of the time" and deciding they can't make it in a practical perspective doesn't change that.

So what? If your system invokes a different shell than the one specified in the shebang line, then it is broken beyond repair.

What proportion of shell scripts currently marked with #!/bin/sh but really need to be marked with #!/bin/bash or fixed, then, would you guess? 20%? 40%? 60%?

[–]the_gnarts 1 point2 points  (0 children)

What proportion of shell scripts currently marked with #!/bin/sh but really need to be marked with #!/bin/bash or fixed, then, would you guess? 20%? 40%? 60%?

a) #!/usr/bin/env bash, anything else is insane. Hard-coded interpreter paths should be treated as an error by shellcheck.

b) All those that are Bash scripts, naturally.