On 11/30/16, Mike Gilbert <[email protected]> wrote:
> On Wed, Nov 30, 2016 at 3:38 AM, konsolebox <[email protected]> wrote:
>> - `[[ ${ROOT} == / ]] || return 0` seems to present a harmless false
>> condition, and it doesn't show an error message. I would be helpful
>> to have a comment added above it to give details why.
>
> We only want to process tmpfiles for the currently running system.
>
> If ROOT is not /, it indicates we are installing the package for use
> on a different system or in a container. In either case, the tmpfiles
> would be processed upon boot when that system/container is started.
>
> I find this fairly obvious, but if William wants to document it that's
> fine.
I'm not familiar with that, and so would other scripters who would
look at the eclass.
>> I also prefer some things this way:
>>
>> - Indent the contents of the first `if` block for consistency's sake,
>> and less confusion.
>
> I disagree; indenting the entire eclass is silly and does not really
> improve readability. Also, this is a very common pattern found in
> other eclasses.
I prefer following consistency before anything else. And it's just
uncommon and odd, but it's not silly. Imagine if you use another `if`
block on the second level where more functions are defined. Would you
also not indent that?
>> - Patterns in the `case` block doesn't have to be indented. This makes
>> the contents of the `case` block aligned with the contents of the
>> other blocks (`if`, `while`, etc.), and it makes the use of indents at
>> minimum when the block is used recursively.
>
> Sorry, I have no idea what you're trying to say here. Recursive blocks?
One expensive in the use of indents:
case $x in
a)
# first inner level
case $y in
1)
# second inner level
case ...
;;
2)
;;
esac
;;
b)
;;
esac
if [ "$x" = a ]; then
# first inner level
if [ "$y" = 1 ]; then
# second inner level
elif [ "$y" = 2 ]; then
:
else
:
fi
elif [ "$x" = b ]; then
:
else
:
fi
vs.
case $x in
a)
case $y in
1)
case ...
;;
2)
;;
esac
;;
b)
;;
esac
> This really feels like you're making a personal style suggestion here,
> and I personally see nothing wrong with it as-is.
Yes the second part is more personal.
--
konsolebox
