On 14-03-02 19:42:30, Allan McRae wrote: > On 02/03/14 19:19, Pierre Neidhardt wrote: > > On 14-03-02 10:01:32, Allan McRae wrote: > >> On 02/03/14 06:14, Pierre Neidhardt wrote: > >>> This maybe a futile question, but not much to lose here so I'm still > >>> asking: > >>> should we let the autotools change the path of the interpreter in the > >>> shabang of > >>> the different scripts? (See makepkg and so on.) > >>> > >>> Actually, according to > >>> > >>> https://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style > >>> > >>> it is said that the interpreter should be /bin/bash, not /usr/bin/bash. > >>> The > >>> latter being far less common. Note that the source files are properly set > >>> to > >>> /bin/*, only the autotools change them to the realpath of the build > >>> system. > >>> > >>> This is really a minor issue, but I believe that switching it back to > >>> /bin/bash > >>> would remove one portability problem for most systems. For instance, to > >>> run > >>> makepkg on a non-Arch system, we download the 'pacman' binary package > >>> first, > >>> from which we extract the 'makepkg' and the 'makepkg.conf' files. Since > >>> the > >>> package was built on an Arch system, the shabang is set to /usr/bin/bash. > >>> On > >>> non-Arch system, we usually need to make to change the shabang back to > >>> /bin/bash. > >>> > >>> What do you think? > >>> > >> > >> Bash is not found in /bin in various BSDs. > >> > >> Allan > > > > > > Right, I was mentionning "most systems", this is no universal solution of > > course. But having this rule in the wiki does not make much sense if the > > shabang > > is automagically generated. > > Pacman development does not care about the Arch wiki. In fact... as > far as I know, Arch development does not care about the bash style wiki > page.
Shouldn't we have a coding style for bash? The HACKING file only mention a coding style for C. There is quite a big amount of bash code in the pacman sources, it could be useful. The wiki page looks rather fine to me. > > By the way makepkg has other portability issues on *BSD systems. So far I > > could > > spot these: > > * bsdtar should be tar. We would need a wrapper function then. > > I only have freebsd to test with, but libarchive installed bsdtar. In > fact, /usr/bin/tar is a symlink to bsdtar. My bad. > > * @SEDINPLACE@ is not portable once autotooled, not standard, and not the > > right > > way to do it anyway. 'ex' should be used instead. For instance (not > > tested) > > Building pacman/makepkg on freebsd, I get sed lines like: > > sed -i "" "s:...:...:" "$BUILDSCRIPT" > > and I have tested that it works as intended. Yes it works, but this is no good practice, see there: http://mywiki.wooledge.org/BashFAQ/021 > > ex -sc "%s:^pkgver=[^ ]*:pkgver=$newpkgver:|xit" "$BUILDFILE" > > > > But maybe the case of *BSD systems is not extremely relevant since they all > > have > > a portage tree and makepkg would not be of much help. In which case the > > shabang > > to /bin/bash makes more sense! :p > > Except for the (at least two) projects creating an Arch like BSD. > > If you have the tools installed to run makepkg on your system and build > almost anything, you have the tools necessary to build pacman. Well, that's a good point :) > Copying a prebuilt makepkg over to a different system is not how you start a > bootstrap. > > Allan -- Pierre Neidhardt Academicians care, that's who.
