From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KhX9r-0005Hv-1h for garchives@archives.gentoo.org; Sun, 21 Sep 2008 22:11:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 60C26E0469; Sun, 21 Sep 2008 22:11:58 +0000 (UTC) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by pigeon.gentoo.org (Postfix) with ESMTP id EA36DE0469 for ; Sun, 21 Sep 2008 22:11:57 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8C996198E09 for ; Mon, 22 Sep 2008 00:11:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 80489198E08 for ; Mon, 22 Sep 2008 00:11:56 +0200 (CEST) Received: from wmax001.mathematik.uni-wuerzburg.de (wmax001.mathematik.uni-wuerzburg.de [132.187.61.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 56DAC198E02 for ; Mon, 22 Sep 2008 00:11:56 +0200 (CEST) Date: Mon, 22 Sep 2008 00:11:30 +0200 (CEST) From: Vaeth To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI In-Reply-To: Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Archives-Salt: 417c6705-a5dc-4f70-b043-3bf3846968a6 X-Archives-Hash: dd1bdb88461878e5ffee4a0d24d20483 Steve Long wrote: > Vaeth wrote: > > > let me remark that the more clever way to this is > > > > [ -n "${DOCS}" ] && eval "dodoc ${DOCS}" > > > eval is _not_ clever. Try: /msg greybot eval > ..or check http://wooledge.org:8000/BashFAQ/048 This is not at all related with my remark: We were speaking about the variable DOCS, which is supposed to be defined by a package author, not by an unreliable source. Of course, unreliable data here may allow execution of arbitrary code, but the package author can execute what he wants anyway. > > This way, people can simply quote as they like: > > > > DOCS="'filename with spaces' filename_without_space doc/*" > > > Yeuch. Well: DOCS=('filename with spaces' filename_without_space doc/*) I cannot see much difference: ( ) vs. " " would optically IMHO not be a reason to discuss, but the former works only in bash, the latter practically everyhwere (and so shell programmers should be used to the latter notation anyway). > > or also > > > > DOCS="just_one_filename_without_special_characters" > > > You don't need quotes there. This is true, but I wanted to show the way most people will use it. > > or also - when Push from /usr/bin/functions-eix.sh is used > > (which might be implemented simpler without using other functions): > > > > Push DOCS 'filename with spaces' filename_without_space "${S}"/doc/* > > > Or just do DOCS+=(foo/* someFile 'some other File') at any point. So the difference is saving two tokens. Is this worth to cement bash-dependency forever in many scripts? > BASH arrays will cope with *any* character apart from NUL, which isn't > allowed in filenames. Can you _guarantee_ the same? Yes, Push does _guarantee_ the same. It is actually rather simple to implement: It puts its argument in '...', separated by spaces, but replaces ' in the arguments before by '\'' (the last part is a bit tricky to do in POSIX [although not really hard - only in functions-eix.sh this is lengthy, because a more general replacement function is used there]. For the time being, I would not even argue against implementing Push in a sourced script in bash: This is only one place to change if one wants more compatibility later on). > For instance, what if some crazy designer puts a file called: > Vaeth's "Latest" Hits > ..in that doc dir no problem at all. > Ebuilds require BASH; get over it. My remark concerning arrays was meant to be general, not specific for ebuilds/portage only (although I couldn't find a passage in the bible where god claimed that ebuilds have to require bash. Actually, 99% of the ebuilds would not need bash, if they would be modified in a completely trivial ways (for the remaining 1% it would need a bit more work)). If one encourages people to write ebuilds compatible, maybe even for portage some day a change is realistic (although I am completely aware that this is not a reasonable project for the near future). > BASH is as portable as GNU make is, and you clearly have no issue > depending on that, and Python or C++. Do you know which shell might be preferrable in 5 years or 10 years? Bets are good that thos shell will at least support POSIX; bets are worse that this shell will support the bash-specific treatment of arrays. > BTW, POSIX sh doesn't need ${DOCS} or ${S} either, you're just wasting > characters. Yes, but that's the gentoo-recommended way to write variables - no need to change the style just for changing it. > > the array-less solution is also much simpler to > > implement, easy to understand from the source, and clearer in usage. > > Not to me it's not, it looks awful, to read and to type, as well as being > fragile. Yes, two symbols to type more is a nightmare :) "Fragile" is not the case as I showed above. > Furthermore you're bringing eval into the script new people are going to > look at to learn from (it's core functionality, fulfilling a basic task) So why should people learn bashisms instead of compatible shell programming? Eval is not bad in itself. It is only bad if used on uncontrolled data which I never suggested. (Actually, a warning in an portage manpage might be didactically more effective concerning the dangers of the uncontrolled usage of eval than many shell introductions.) > >> if isArr DOCS; then > >> ((${#DOCS[@]})) && dodoc "${DOCS[@]}" > >> else [[ $DOCS ]] && dodoc $DOCS > >> fi > > > > are just awful. > > Actually if you factor out that isArr is a utility function (exactly like > Push) that code is very easy to follow Maybe my explanation was unclear here: I am not speaking about the code. I am speaking about the way it behaves. DOCS='"a b"' -> two files `"a' and `b"' DOCS=('"a b"') -> one file `"a b"' this is just creating confusion by special cases. If you say instead the argument is eval'ed, everybody who knows any shell knows what is going on and that you have to quote correspondingly. And the case distinction is necessary, since for arrays you cannot shortcut (i.e. you can _never_ avoid the ( ) part) - for variables you can (as you mentioned, in most cases you can even avoid the " " part). > I'm willing to bet your sh scripts aren't really as portable as you think. > If you want to see how portable sh is done, read: > http://sources.redhat.com/autobook/autobook/autobook_210.html#SEC210 > (all of it) and then try to persuade us that we should be writing ebuilds > like that. This is an old rhetorical trick (I don't know its name in English): You impute that I claimed things which I never said - of course, then it is easy for you to prove that these things are wrong. I _never_ suggested to use code from stone-age for ebuilds (I did more for the eix scripts, and I think that I succeeded meanwhile for all architectures supported by gentoo, but I did never suggest this for everybody. BTW: Even for these architectures only very few differences from POSIX arose - these really old shells which do not have even functions or other odd bugs seem to have really extinct. But this is a different topic). However, I strongly suggest to avoid bashisms unless absolutely necessary and reasonable. There are scripts where this is reasonable, but far too many scripts which use it do not belong to this category. Using arrays to pass parameters is one of the cases of unnecessary usage (although this is not widely known - that's that main reason why I posted the remark).