[pacman-dev] Shabang in scripts
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? -- Pierre Neidhardt Oh, get ahold of yourself. Nobody's proposing that we parse English. -- Larry Wall in <199709032332.QAA21669@wall.org>
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
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. 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. * @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) 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 -- Pierre Neidhardt Conversation enriches the understanding, but solitude is the school of genius.
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.
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.
* @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.
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. Copying a prebuilt makepkg over to a different system is not how you start a bootstrap. Allan
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.
participants (2)
-
Allan McRae
-
Pierre Neidhardt