Export options as environment variables

[YerinAlexey]

All options will be available in commands via lf_OPTION environment variables

Closes #443, closes #376

[gokcehan]

@YerinAlexey Thanks for the patch. I never considered using reflect to simplify things here.

Is it possible to also add sortType manually somehow? I think some people might be upset when these options are missing (e.g. #411 specifically mentions hidden option). Though if you don't want to work on it, we can leave it for later.

I see you also you 1 and 0 to represent true and false in booleans. Booleans are kind of confusing in shell because return codes use the reverse semantic compared to C-family languages (i.e. return 0 for success, non-zero for fail). I was thinking, maybe values true and false might be a better approach for booleans. Since they are shell builtins, they could be used as follows:

if $lf_number; then
    echo 'numbers are enabled'
else
    echo 'numbers are disabled'
fi

What do you think?

[YerinAlexey]

Is it possible to also add sortType manually somehow?

Yes, I'll add it.

I see you also you 1 and 0 to represent true and false in booleans. Booleans are kind of confusing in shell because return codes use the reverse semantic compared to C-family languages (i.e. return 0 for success, non-zero for fail). I was thinking, maybe values true and false might be a better approach for booleans.

I also think true/false for booleans are better. I'll fix them soon.

[gokcehan]

@YerinAlexey Since true and false are the same in Go, there is strconv.FormatBool function you can use to get rid of conditionals if you like.

[YerinAlexey]

@YerinAlexey Since true and false are the same in Go, there is strconv.FormatBool function you can use to get rid of conditionals if you like.

Thanks for advice, I didn't know about this function before

[gokcehan]

@YerinAlexey It seems good to me. Thank you again for implementing this.

[SeerLite]

Thank you so much for implementing this! It works perfectly!

I see you also you 1 and 0 to represent true and false in booleans. Booleans are kind of confusing in shell because return codes use the reverse semantic compared to C-family languages (i.e. return 0 for success, non-zero for fail). I was thinking, maybe values true and false might be a better approach for booleans. Since they are shell builtins, they could be used as follows:

if $lf_number; then
    echo 'numbers are enabled'
else
    echo 'numbers are disabled'
fi

Hey, I don't actually like this idea at all because it encourages the execution of arbitrary variables. Having a stricter (although more verbose) representation of the variables sounds like a more secure approach. Besides, it makes it a bit more consistent with non-boolean variables: You'd have to test or [ <...> = <...> ] both kinds.

Note: Currently, doing [ <...> = "true" ] also works. I just wanted to give my opinion on this: naming booleans true and false with the intention of them being executed sounds like a bad idea.

[gokcehan]

@SeerLite You have a point, though I can't think of any scenario where the values can be set to arbitrary commands to be executed which is otherwise not possible. I can see how some people may try to accidentally execute non-boolean variables (e.g. if $lf_ratios; then ...), though this will likely end up with garbage errors at worst.

Anyway, [ <...> = "true" ] seems perfectly fine. It is often a good idea to be explicit about things. Though I should note that [ and test have their own quirks. For example, this might fail depending on the quoting rules of your shell when the variable is empty (e.g. when you're using an older version of lf where options were not available). Also you should be aware the option value does not contain anything that starts with - to be confused as flags to [ and test commands.

[SeerLite]

I can't think of any scenario where the values can be set to arbitrary commands to be executed which is otherwise not possible.

Currently, me neither. But that doesn't mean that something like this can't come up in the future!
I understand if you think it's ok to leave it like this for now though.

For example, this might fail depending on the quoting rules of your shell when the variable is empty (e.g. when you're using an older version of lf where options were not available)

I'm assuming POSIX shell for this, and I think test is a lot safer. If the variable is empty, it's gonna be parsed as [ "" = 1] which IMO is a lot nicer than, when executing inside an if, it ends up like: if ; then.
I just tested this in bash and dash, if $empty-var; then always succeeds, which I think is quite counter-intuitive.

Also you should be aware the option value does not contain anything that starts with - to be confused as flags to [ and test commands.

I tested this and as long as there's a = in the command, - aren't parsed as flags. I'm not sure if this is officially defined in POSIX but it worked in dash, bash and busybox shell. Considering this, I think test is pretty safe to use.