1 |
Roy Marples wrote: |
2 |
|
3 |
> On Tue, 2007-10-16 at 13:38 +0100, Steve Long wrote: |
4 |
>> Roy Marples wrote: |
5 |
>> > On Tue, 2007-10-16 at 00:28 -0700, Donnie Berkholz wrote: |
6 |
>> >> On 08:19 Tue 16 Oct , Steve Long wrote: |
7 |
>> >> > stdDocs=(ChangeLog AUTHORS FEATURES THANKS README CodingStyle TODO |
8 |
>> >> > FAQ) |
9 |
>> >> > |
10 |
>> >> > stdDoc() { |
11 |
>> >> > local d l=() |
12 |
>> >> > for d in "${stdDocs[@]}"; do |
13 |
>> >> > [[ -f $d ]] && l+=("$d") |
14 |
>> >> > done |
15 |
>> >> > ((${#l[@]})) && dodoc "${l[@]}" |
16 |
>> >> > } |
17 |
>> >> > |
18 |
>> >> > (assuming [[ $PWD = $S ]] or whichever is the right one for docs.) |
19 |
>> >> |
20 |
>> >> Is it just me, or is this code way more complex than it needs to be? |
21 |
>> >> It looks like bashturbation to me. =P |
22 |
>> > |
23 |
>> LMAO. It's as complex as it needs to be to handle filenames with spaces |
24 |
>> or any other character in. Remember: "Looks like it needs quotes there.. |
25 |
>> $D, $S.." What, I should write crap script for this esteemed audience, |
26 |
>> cos you only currently deal with filenames without spaces? ;P |
27 |
> |
28 |
> No, it's overly complex. Consider this |
29 |
> |
30 |
> stddoc() { |
31 |
> local d |
32 |
> for d in ChangeLog AUTHORS FEATURES THANKS README \ |
33 |
> CodingStyle TODO FAQ; do |
34 |
> [ -f "${d}" ] && dodoc "${f}" |
35 |
> done |
36 |
> } |
37 |
> |
38 |
> Want spaces? |
39 |
> |
40 |
> stddoc() { |
41 |
> local d |
42 |
> for d in ChangeLog AUTHORS FEATURES THANKS README \ |
43 |
> CodingStyle TODO FAQ "a file with spaces"; do |
44 |
> [ -f "${d}" ] && dodoc "${f}" |
45 |
> done |
46 |
> } |
47 |
> |
48 |
> Or maybe you want to do it on one hit? |
49 |
> |
50 |
> stddoc() { |
51 |
> local d |
52 |
> set -- |
53 |
> for d in ChangeLog AUTHORS FEATURES THANKS README \ |
54 |
> CodingStyle TODO FAQ "a file with spaces"; do |
55 |
> [ -f "${d}" ] && set -- "$@" "${f}" |
56 |
> done |
57 |
> dodoc "$@" |
58 |
> } |
59 |
> |
60 |
> |
61 |
OK, that's all good, and you're _right_ for this case. I guess I was trying |
62 |
to show an array being used since it came up before. For instance, I often |
63 |
add to a global array with eg failed+=("$1"), which I might display |
64 |
one-per-line to the user with: IFS=$'\n'; echo "${failed[*]}". This is |
65 |
handy for tab separated data as well, if one uses IFS=$'\t' (also affects |
66 |
read.) |
67 |
|
68 |
The use of an array like that still seem pertinent to me: for instance in an |
69 |
eclass as something the ebuild can add to, or indeed as a dataset the |
70 |
eclass builds up in cooperation with the ebuild. An example of that might |
71 |
be checking php use flags; the ebuild is only interested in a subset, and |
72 |
the eclass would only run the checks on those. |
73 |
|
74 |
In any event it's a useful construct imo, for a set that can be added to as |
75 |
and when. |
76 |
|
77 |
>> > You can also do some pattern matching like so |
78 |
>> > |
79 |
>> > foo="foo foobar" |
80 |
>> > |
81 |
>> > [ "${foo%foobar}" = "${foo}" ] || echo "ends with foobar" |
82 |
>> [[ $foo = *foobar ]] && echo "ends with foobar" |
83 |
>> |
84 |
>> > [ "${foo#foobar}" = "${foo}" ] || echo "starts with foo" |
85 |
>> [[ $foo = foo* ]] && echo 'oh does it?' |
86 |
>> There's no need for borked script that is counter-intuitive, and doesn't |
87 |
>> have a third of the functionality either. |
88 |
> |
89 |
> I maybe wrong, but shouldn't you be using == inside [[ ]]? |
90 |
> |
91 |
No. == works, but = is considered better script style in #bash since it's |
92 |
the same as standard [ and implies you know you're in shell, not C. I use |
93 |
it since it's the script I see in front of me all the time, and it's _less |
94 |
typing_. == is required in ((..)) (For the BASH additions, *and* how to |
95 |
stay compatible see [1].) |
96 |
|
97 |
>> [[ $foo = *'wow it '*"does as $well"* ]] && echo 'And a whole lot more!' |
98 |
> |
99 |
> case "${foo}" in |
100 |
> *'wow it '*"does as $well"*) && echo "whatever you can do i can do in |
101 |
> sh";; |
102 |
> esac |
103 |
> |
104 |
>> Or should *nix only ever support |
105 |
>> POSIX APIs for everything? #define _X_OPEN_SOURCE? No? Hmm.. *shrug* ;> |
106 |
> |
107 |
> No, I saying use whatever god given extensions you like. But if there's |
108 |
> a portable way of doing the same thing then please use the portable way |
109 |
> of doing it. |
110 |
> |
111 |
The thing is bashisms make my life easier: the code is clearer, and easier |
112 |
to comprehend, write and maintain. While ebuilds aren't full-blown |
113 |
applications, the same principles apply to the script, especially when so |
114 |
few devs have to maintain so many ebuilds. IMO script that takes twice as |
115 |
long to parse and write is a Bad Thing (tm): even if it only adds a minute |
116 |
or two to the average quick fix, across the tree that adds up. |
117 |
|
118 |
So given that the Unix world, while still supporting POSIX as a base, also |
119 |
has added other, newer standards, I don't see the benefit in not using |
120 |
them. The only use-case that made any sense to me was someone using |
121 |
OpenMoko, or a Motorola phone with its own complete Linux (as opposed to |
122 |
the usual embedded space.) IMO someone who bothers to install a full blown |
123 |
Linux on a phone will have a desktop they can use as Build host, and a |
124 |
better use of dev time is to write the tools to enable that (it'd also be a |
125 |
lot quicker), than to convert all the ebuilds to sh, and slow future dev |
126 |
down by making devs use sh syntax. |
127 |
|
128 |
It's funny: there is actually a lot of emphasis given in #bash on |
129 |
portability. People are routinely told not to rely on GNU command options, |
130 |
and there is even occasional discussion of sh. It's just that bash runs on |
131 |
so many platforms (including greycat's crusty HP-UX from 1995) and has |
132 |
become a de-facto standard: if people use other shells, those also |
133 |
typically support constructs like arrays, and usually add even more, |
134 |
non-POSIX, stuff than bash. |
135 |
|
136 |
>> /me wanders down the pub.. *plop* |
137 |
> |
138 |
> Yeah, I'd drown my sorrows if I wrote shell script like you :P |
139 |
> |
140 |
Lol, yeah well I would if i had to write in sh, it's rough! ;) Each to their |
141 |
own, eh? |
142 |
|
143 |
Regards, |
144 |
igli. |
145 |
|
146 |
[1] http://wooledge.org/mywiki/ArithmeticExpression |
147 |
|
148 |
|
149 |
-- |
150 |
gentoo-dev@g.o mailing list |