1 |
On 11/30/16, Mike Gilbert <floppym@g.o> wrote: |
2 |
> On Wed, Nov 30, 2016 at 3:38 AM, konsolebox <konsolebox@×××××.com> wrote: |
3 |
>> - `[[ ${ROOT} == / ]] || return 0` seems to present a harmless false |
4 |
>> condition, and it doesn't show an error message. I would be helpful |
5 |
>> to have a comment added above it to give details why. |
6 |
> |
7 |
> We only want to process tmpfiles for the currently running system. |
8 |
> |
9 |
> If ROOT is not /, it indicates we are installing the package for use |
10 |
> on a different system or in a container. In either case, the tmpfiles |
11 |
> would be processed upon boot when that system/container is started. |
12 |
> |
13 |
> I find this fairly obvious, but if William wants to document it that's |
14 |
> fine. |
15 |
|
16 |
I'm not familiar with that, and so would other scripters who would |
17 |
look at the eclass. |
18 |
|
19 |
>> I also prefer some things this way: |
20 |
>> |
21 |
>> - Indent the contents of the first `if` block for consistency's sake, |
22 |
>> and less confusion. |
23 |
> |
24 |
> I disagree; indenting the entire eclass is silly and does not really |
25 |
> improve readability. Also, this is a very common pattern found in |
26 |
> other eclasses. |
27 |
|
28 |
I prefer following consistency before anything else. And it's just |
29 |
uncommon and odd, but it's not silly. Imagine if you use another `if` |
30 |
block on the second level where more functions are defined. Would you |
31 |
also not indent that? |
32 |
|
33 |
>> - Patterns in the `case` block doesn't have to be indented. This makes |
34 |
>> the contents of the `case` block aligned with the contents of the |
35 |
>> other blocks (`if`, `while`, etc.), and it makes the use of indents at |
36 |
>> minimum when the block is used recursively. |
37 |
> |
38 |
> Sorry, I have no idea what you're trying to say here. Recursive blocks? |
39 |
|
40 |
One expensive in the use of indents: |
41 |
|
42 |
case $x in |
43 |
a) |
44 |
# first inner level |
45 |
case $y in |
46 |
1) |
47 |
# second inner level |
48 |
case ... |
49 |
;; |
50 |
2) |
51 |
;; |
52 |
esac |
53 |
;; |
54 |
b) |
55 |
;; |
56 |
esac |
57 |
|
58 |
if [ "$x" = a ]; then |
59 |
# first inner level |
60 |
if [ "$y" = 1 ]; then |
61 |
# second inner level |
62 |
elif [ "$y" = 2 ]; then |
63 |
: |
64 |
else |
65 |
: |
66 |
fi |
67 |
elif [ "$x" = b ]; then |
68 |
: |
69 |
else |
70 |
: |
71 |
fi |
72 |
|
73 |
vs. |
74 |
|
75 |
case $x in |
76 |
a) |
77 |
case $y in |
78 |
1) |
79 |
case ... |
80 |
;; |
81 |
2) |
82 |
;; |
83 |
esac |
84 |
;; |
85 |
b) |
86 |
;; |
87 |
esac |
88 |
|
89 |
> This really feels like you're making a personal style suggestion here, |
90 |
> and I personally see nothing wrong with it as-is. |
91 |
|
92 |
Yes the second part is more personal. |
93 |
|
94 |
-- |
95 |
konsolebox |