Re: [hackers] [farbfeld] Shellcheck 2ff fixes || FRIGN

From: Evan Gates <evan.gates_AT_gmail.com>
Date: Wed, 7 Sep 2016 15:52:48 -0700

On Wed, Sep 7, 2016 at 3:26 PM, FRIGN <dev_AT_frign.de> wrote:
> Yes it is a reflex. The semicolons don't hurt anybody and I actually am
> not that much of a shell-god to really exactly know where I can get rid
> of them.

Anywhere you have a single semicolon at the end of the line you can
get rid of it.

>> Why not quote "$ret"? You don't have control over the environment in
>> which the user will run the script. I know it sounds stupid, but I
>> have literally seen a script run in a case where IFS=0 and if [ $? -ne
>> 0 ] broke. And it was a legitimate usage.
>
> I don't know about such environments. The question is if $? would ever
> return something that is something else than a number.

$? should always be a number. But some times IFS, the internal field
separator, can be set to weird values. Normally IFS is set to space,
tab, newline. When performing word splitting the shell splits on the
values in IFS. If a user happened to set IFS=0 and $? is 0, then $?
expands to nothing. Try this (I put it in a subshell so you don't lose
your IFS):

(IFS=0; true; if [ $? -ne 0 ]; then echo foo; fi)

You should get [ telling you that an integer expression was expected.

Does it make sense to have a weird IFS like that? Maybe, we don't know
what the user is doing. Is IFS inherited through the environment?
Maybe, different shells behave differently in this area even though
POSIX says it should be (e.g. bash doesn't).

> I honestly have to say that I'm not comfortable with those shell-tricks
> and in my opinion this lowers readability very much. If this was a part
> of the script that was executed 1 million times I would think about
> using "shell-native" functions, but this is just done once and you
> immediately see what it does because cut(1) is a common tool.
>
> For shells, I like to go for the UNIX approach. Use the provided Posix
> tools to solve a task and avoid builtin stuff, especially magic syntax,
> as much as possible.

That's fine, and I think that's a good enough reason to leave it as
is. I don't think it's something a shell needs (notice rc doesn't have
all that stuff, you always use external tools), just something I have
grown used to and don't avoid as it's in POSIX.
Received on Thu Sep 08 2016 - 00:52:48 CEST