Max Miorim | 30 Oct 12:28 2010
Picon

Patch proposal to remove bashisms from some scripts

Hello folks,

Recently I have been tinkering with one of my boxes to use ash as
/bin/sh and noticed that doing so some SlackBuilds aren't working as
intended anymore.

After some debugging (ol' good "set -x"), I have noticed some
"bashisms" such as the use of [[ ]] instead of [ ] or test and the use
of == instead of = in either [ ] or test and so I'm proposing
modifications (see attached patch) to remove the bashisms of the
following scripts (whose maintainers are CC'ed):

./development/cppcheck/cppcheck.SlackBuild
./libraries/Jinja2/Jinja2.SlackBuild
./libraries/gdal/gdal.SlackBuild
./libraries/python-musicbrainz2/python-musicbrainz2.SlackBuild
./office/go_openoffice/go_openoffice.SlackBuild
./office/adobe-reader-fontpacks/adobe-reader-fontpacks.SlackBuild
./network/skype/skype.SlackBuild
./network/ekiga/ekiga.SlackBuild
./network/ngrep/ngrep.SlackBuild
./desktop/openbox/openbox.SlackBuild
./desktop/synergy-plus/synergy-plus.SlackBuild
./desktop/vwm/vwm.SlackBuild
./misc/ophcrack/ophcrack.SlackBuild
./misc/dwdiff/dwdiff.SlackBuild
./multimedia/xbmc/xbmc.SlackBuild
./audio/herrie/herrie.SlackBuild
./games/jag/jag.SlackBuild
./games/openttd/openttd.SlackBuild
(Continue reading)

Mikko Varri | 30 Oct 12:51 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On Sat, Oct 30, 2010 at 08:28:35AM -0200, Max Miorim wrote:
> 
> ./libraries/Jinja2/Jinja2.SlackBuild
> 

Perfect timing, Max!  I'm just preparing an update of
Jinja2.SlackBuild.  Thank you.

-vmj
David Spencer | 30 Oct 12:58 2010

Re: Patch proposal to remove bashisms from some scripts

> Recently I have been tinkering with one of my boxes to use ash as
> /bin/sh and noticed that doing so some SlackBuilds aren't working as
> intended anymore.

I once did something similar with ksh, so I sympathise with your
intentions :-) and I'm rather shocked to be a three-strike offender
:-(

But I don't think the patch will work for grass.SlackBuild, which uses
arrays due to bash's brain-dead whitespace handling. It can't be made
to work in bash using only ash-compatible code, and most people will
have bash as /bin/sh.  SlackBuild.org policy is that a full Slackware
installation is required, and a full Slackware installation includes
bash, so perhaps the easy solution would be to use '#!/bin/bash' in
scripts that really need bash functionality?

But you're right that, in most cases, bash-specific code is trivially
easy to avoid, and therefore I'll take a bit more care to do that in
future.

I'll leave the question of whether this needs a mass patch at SBo to
the SBo admins.  If it doesn't, I'll quietly update my SlackBuilds the
next time they need revision for other reasons.

-D.

(cc trimmed, as presumably most people are subscribed to slackbuilds-users)
Eric Hameleers | 30 Oct 13:30 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On Sat, 30 Oct 2010, David Spencer wrote:

>> Recently I have been tinkering with one of my boxes to use ash as
>> /bin/sh and noticed that doing so some SlackBuilds aren't working as
>> intended anymore.
>
> I'll leave the question of whether this needs a mass patch at SBo to
> the SBo admins.  If it doesn't, I'll quietly update my SlackBuilds the
> next time they need revision for other reasons.

Slackware assumes and requires that the root user uses bash as the 
default shell. Not just SlackBuild scripts but the init scripts will not 
all work the full 100% when using a limited version like ash.

We are not going to demand or execute a mass patch here at SlackBuilds.org 
- we keep assuming that /bin/sh is linked to /bin/bash .

Cheers, Eric

--

-- 
Eric Hameleers
Email: alien@...
Jabber: alien@...
Gpg fingerprint: F2CE 1B92 EE1F 2C0C E97E  581E 5E56 AAAF A75C BDA0

The two basic principles of Windows system administration:
* For minor problems, reboot
* For major problems, reinstall
Max Miorim | 30 Oct 14:40 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On Sat, Oct 30, 2010 at 9:30 AM, Eric Hameleers <eha <at> alienbase.nl> wrote:
> On Sat, 30 Oct 2010, David Spencer wrote:
>
>>> Recently I have been tinkering with one of my boxes to use ash as
>>> /bin/sh and noticed that doing so some SlackBuilds aren't working as
>>> intended anymore.
>>
>> I'll leave the question of whether this needs a mass patch at SBo to
>> the SBo admins.  If it doesn't, I'll quietly update my SlackBuilds the
>> next time they need revision for other reasons.
>
> Slackware assumes and requires that the root user uses bash as the default
> shell. Not just SlackBuild scripts but the init scripts will not all work
> the full 100% when using a limited version like ash.

Yeah, I have had to modify the init scripts to work around some
problems like the absence of arrays in ash.

> We are not going to demand or execute a mass patch here at SlackBuilds.org -
> we keep assuming that /bin/sh is linked to /bin/bash .

Although I don't like the assumption that /bin/sh is linked to bash
(I'd rather use #!/bin/bash to ensure that I'm using the right shell),
I kind of understand the reasons for doing so.

I will modify my sbopkg to run "bash $PKGNAME.SlackBuild.build"
instead of sh and just use "bash script.SlackBuild" from now on. :)

-- Max
_______________________________________________
(Continue reading)

xgizzmo | 30 Oct 15:00 2010

Re: Patch proposal to remove bashisms from some scripts

On Saturday 30 October 2010 08:40:58 Max Miorim wrote:
> On Sat, Oct 30, 2010 at 9:30 AM, Eric Hameleers <eha <at> alienbase.nl> wrote:
> > On Sat, 30 Oct 2010, David Spencer wrote:
> >
> >>> Recently I have been tinkering with one of my boxes to use ash as
> >>> /bin/sh and noticed that doing so some SlackBuilds aren't working as
> >>> intended anymore.
> >>
> >> I'll leave the question of whether this needs a mass patch at SBo to
> >> the SBo admins.  If it doesn't, I'll quietly update my SlackBuilds the
> >> next time they need revision for other reasons.
> >
> > Slackware assumes and requires that the root user uses bash as the default
> > shell. Not just SlackBuild scripts but the init scripts will not all work
> > the full 100% when using a limited version like ash.
> 
> Yeah, I have had to modify the init scripts to work around some
> problems like the absence of arrays in ash.
> 
> 
> > We are not going to demand or execute a mass patch here at SlackBuilds.org -
> > we keep assuming that /bin/sh is linked to /bin/bash .
> 
> Although I don't like the assumption that /bin/sh is linked to bash
> (I'd rather use #!/bin/bash to ensure that I'm using the right shell),
> I kind of understand the reasons for doing so.
> 
> I will modify my sbopkg to run "bash $PKGNAME.SlackBuild.build"
> instead of sh and just use "bash script.SlackBuild" from now on. :)
> 
(Continue reading)

slakmagik | 30 Oct 19:50 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On 2010-10-30 (Sat) 09:00:11 [-0400], xgizzmo@... wrote:
> On Saturday 30 October 2010 08:40:58 Max Miorim wrote:
> > On Sat, Oct 30, 2010 at 9:30 AM, Eric Hameleers <eha@...> wrote:
> > > On Sat, 30 Oct 2010, David Spencer wrote:
> > >
> > >>> Recently I have been tinkering with one of my boxes to use ash as
> > >>> /bin/sh and noticed that doing so some SlackBuilds aren't working as
> > >>> intended anymore.
> > >>
> > >> I'll leave the question of whether this needs a mass patch at SBo to
> > >> the SBo admins. If it doesn't, I'll quietly update my SlackBuilds the
> > >> next time they need revision for other reasons.
> > >
> > > Slackware assumes and requires that the root user uses bash as the default
> > > shell. Not just SlackBuild scripts but the init scripts will not all work
> > > the full 100% when using a limited version like ash.
[snip]
> > > We are not going to demand or execute a mass patch here at SlackBuilds.org -
> > > we keep assuming that /bin/sh is linked to /bin/bash .
[snip]
> Thanks for your work on this. While we will not demand these changes be made
> the maintainers of affected builds are free to make these changes if they wish.
>
> --dsomero

Your patch won't work in some cases - I'm guilty of using '[[' in dwdiff
and mtpaint but I also leave $VAR unquoted. Merely changing it to '['
will result in ash choking on either an unexpected operator or an
expected argument if the variable is unset. But, as others have said,
thanks for bringing it to my/our attention. I agree with the policy that
(Continue reading)

B Kirkpatrick | 31 Oct 15:15 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On 10/30/2010 12:50 PM, slakmagik wrote:
> On 2010-10-30 (Sat) 09:00:11 [-0400], xgizzmo@... wrote:
>> On Saturday 30 October 2010 08:40:58 Max Miorim wrote:
>>> On Sat, Oct 30, 2010 at 9:30 AM, Eric Hameleers<eha@...>  wrote:
>>>> On Sat, 30 Oct 2010, David Spencer wrote:
>>>>
>>>>>> Recently I have been tinkering with one of my boxes to use ash as
>>>>>> /bin/sh and noticed that doing so some SlackBuilds aren't working as
>>>>>> intended anymore.
>>>>> I'll leave the question of whether this needs a mass patch at SBo to
>>>>> the SBo admins. If it doesn't, I'll quietly update my SlackBuilds the
>>>>> next time they need revision for other reasons.
>>>> Slackware assumes and requires that the root user uses bash as the default
>>>> shell. Not just SlackBuild scripts but the init scripts will not all work
>>>> the full 100% when using a limited version like ash.
> [snip]
>>>> We are not going to demand or execute a mass patch here at SlackBuilds.org -
>>>> we keep assuming that /bin/sh is linked to /bin/bash .
> [snip]
>> Thanks for your work on this. While we will not demand these changes be made
>> the maintainers of affected builds are free to make these changes if they wish.
>>
>> --dsomero
> Your patch won't work in some cases - I'm guilty of using '[[' in dwdiff
> and mtpaint but I also leave $VAR unquoted. Merely changing it to '['
> will result in ash choking on either an unexpected operator or an
> expected argument if the variable is unset. But, as others have said,
> thanks for bringing it to my/our attention. I agree with the policy that
> sh is bash and that these changes aren't mandatory but also agree
> that SlackBuilds shouldn't be needlessly bashistic and I'll modify mine
(Continue reading)

Mikko Varri | 31 Oct 15:44 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On Sun, Oct 31, 2010 at 09:15:58AM -0500, B Kirkpatrick wrote:
> 
> I do not want to start a flame war here, but I would like an
> explanation of why the large majority of Slackware users, those who
> have & use bash, have to write ash-compliant scripts for those who
> are using that shell. I know that it has been done that way forever,
> I know that ash is run during install, I know that it is run in
> BusyBox, but when the system is installed, why can't I write any
> bash-compliant code & not get "bashed" by other users?
> 

As admins already said, you don't have to.  But, IMHO, if contributing
those scripts to a larger community, it would make sense to try to be
a good citizen... if you can, that is; some features just don't exist
in ash.

-vmj
Ben Mendis | 1 Nov 08:50 2010
Picon

Re: Patch proposal to remove bashisms from some scripts


On Sun, Oct 31, 2010 at 10:15 AM, B Kirkpatrick <bkirkp <at> gmail.com> wrote:
I do not want to start a flame war here, but I would like an explanation of why the large majority of Slackware users, those who have & use bash, have to write ash-compliant scripts for those who are using that shell. I know that it has been done that way forever, I know that ash is run during install, I know that it is run in BusyBox, but when the system is installed, why can't I write any bash-compliant code & not get "bashed" by other users?
Regards,
Bill


My personal feeling has always been that if the script begins with #!/bin/sh then it should be written to work with _any_ Bourne-compatible shell. If you want/need to use features specific to a particular implementation such as Bash or Ksh, then state that explicitly in your shebang. If you're unsure, put #!/bin/bash or whatever shell you tested in.

Demanding to use Bash-specific features in Bourne shell is like demanding a garbage collector in C.
<div>
<br><div class="gmail_quote">On Sun, Oct 31, 2010 at 10:15 AM, B Kirkpatrick <span dir="ltr">&lt;<a href="mailto:bkirkp@...">bkirkp <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

I do not want to start a flame war here, but I would like an explanation of why the large majority of Slackware users, those who have &amp; use bash, have to write ash-compliant scripts for those who are using that shell. I know that it has been done that way forever, I know that ash is run during install, I know that it is run in BusyBox, but when the system is installed, why can't I write any bash-compliant code &amp; not get "bashed" by other users?<br>

Regards,<br>
Bill<div>
<div></div>
<div class="h5"><br></div>
</div>
</blockquote>
<div>
<br>My personal feeling has always been that if the script begins with #!/bin/sh then it should be written to work with _any_ Bourne-compatible shell. If you want/need to use features specific to a particular implementation such as Bash or Ksh, then state that explicitly in your shebang. If you're unsure, put #!/bin/bash or whatever shell you tested in. <br><br>Demanding to use Bash-specific features in Bourne shell is like demanding a garbage collector in C. <br>
</div>
</div>
</div>
Eric Hameleers | 1 Nov 12:24 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On Mon, 1 Nov 2010, Ben Mendis wrote:

> On Sun, Oct 31, 2010 at 10:15 AM, B Kirkpatrick <bkirkp@...> wrote:
>
>> I do not want to start a flame war here, but I would like an explanation of
>> why the large majority of Slackware users, those who have & use bash, have
>> to write ash-compliant scripts for those who are using that shell. I know
>> that it has been done that way forever, I know that ash is run during
>> install, I know that it is run in BusyBox, but when the system is installed,
>> why can't I write any bash-compliant code & not get "bashed" by other users?
>> Regards,
>> Bill
>>
>>
> My personal feeling has always been that if the script begins with #!/bin/sh
> then it should be written to work with _any_ Bourne-compatible shell. If you
> want/need to use features specific to a particular implementation such as
> Bash or Ksh, then state that explicitly in your shebang. If you're unsure,
> put #!/bin/bash or whatever shell you tested in.
>
> Demanding to use Bash-specific features in Bourne shell is like demanding a
> garbage collector in C.

The SlackBuild scripts hosted by http://slackbuilds.org have to be 
executed by the root user. Slackware assumes that the root user uses the 
bash shell. I agree though that /bin/sh can point to any shell the local 
computer administrator likes best. So, bashisms should be kept to a 
minimum in SlackBuild scripts, and if anything is used that works only 
with bash, the shebang line should read "#!/bin/bash" explicitly.

However!
I do not want a "bash test" to be mandatory for the SlackBuild maintainer. 
Rather, I would like to leave it to the users of the script to report 
incompatibilities.

If any user of a script finds that the script actually requires bash, he 
or she can communicate this to the maintainer who can then update the 
SlackBuild with an explicit "#!/bin/bash" line.

Note that this is my personal opinion, not discussed with the other 
admins.

Cheers, Eric
--

-- 
Eric Hameleers
Email: alien@...
Jabber: alien@...
Gpg fingerprint: F2CE 1B92 EE1F 2C0C E97E  581E 5E56 AAAF A75C BDA0

The two basic principles of Windows system administration:
* For minor problems, reboot
* For major problems, reinstall
R. Andrew Bailey | 1 Nov 12:37 2010

Re: Patch proposal to remove bashisms from some scripts

On 30/10/10 06:28 -0400, Max Miorim wrote:
>Hello folks,
>
>Recently I have been tinkering with one of my boxes to use ash as

...

  Don't you think its a lot easier for you to remember to exec these
  scripts with bash, than to get everybody else to change their scripts
  to work with your symlink? :)

  .andy

>Regards,
>
>Max

>_______________________________________________
>SlackBuilds-users mailing list
>SlackBuilds-users@...
>http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - http://slackbuilds.org/faq/
>

David Spencer | 1 Nov 13:00 2010

Re: Patch proposal to remove bashisms from some scripts

>  Don't you think its a lot easier for you to remember to exec these
>  scripts with bash, than to get everybody else to change their scripts
>  to work with your symlink? :)

Technical measures are always better than "remembering". That's what
"#!/bin/bash" is for.

What follows is just a personal opinion. I try to write my scripts to
the highest standards. If I start with #!/bin/sh, and then I write a
bashism, then #!/bin/sh was a lie, and when someone points that out, I
am embarassed and grateful, especially when the fix is really, really
easy.  I'm not "everybody", but then, not everybody's script starts
with a lie.  Just three of mine :-/

-D.
R. Andrew Bailey | 1 Nov 13:27 2010

Re: Patch proposal to remove bashisms from some scripts

On 01/11/10 08:00 -0400, David Spencer wrote:
>>  Don't you think its a lot easier for you to remember to exec these
>>  scripts with bash, than to get everybody else to change their scripts
>>  to work with your symlink? :)
>
>Technical measures are always better than "remembering". That's what
>"#!/bin/bash" is for.
>
>What follows is just a personal opinion. I try to write my scripts to
>the highest standards. If I start with #!/bin/sh, and then I write a
>bashism, then #!/bin/sh was a lie, and when someone points that out, I
>am embarassed and grateful, especially when the fix is really, really
>easy.  I'm not "everybody", but then, not everybody's script starts
>with a lie.  Just three of mine :-/

So changing the shbang lines to read #!/bin/bash would suffice, no?

  .andy

>
>-D.
>_______________________________________________
>SlackBuilds-users mailing list
>SlackBuilds-users@...
>http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - http://slackbuilds.org/faq/
David Spencer | 1 Nov 14:04 2010

Re: Patch proposal to remove bashisms from some scripts

> So changing the shbang lines to read #!/bin/bash would suffice, no?

Yes.  That's what pretty much everyone has been saying since the start
of this discussion.  Which is ok, really; it helps keep the mailing
list ticking over.

-D.
King Beowulf | 1 Nov 14:07 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

I would say so.

My 2 cents: SBo hosts packages for Slackware. Slackware default shell
is bash. Slackbuild scripts should be bash compliant.  Anything else
is an exercise for the end user (eg dependency resolution etc).

Personally, I have a hard enough time keeping up with bash; I have no
interest in the globs of other shells out there.

-Ed

On 11/1/10, R. Andrew Bailey <bailey@...> wrote:
> On 01/11/10 08:00 -0400, David Spencer wrote:
>>>  Don't you think its a lot easier for you to remember to exec these
>>>  scripts with bash, than to get everybody else to change their scripts
>>>  to work with your symlink? :)
>>
>>Technical measures are always better than "remembering". That's what
>>"#!/bin/bash" is for.
>>
>>What follows is just a personal opinion. I try to write my scripts to
>>the highest standards. If I start with #!/bin/sh, and then I write a
>>bashism, then #!/bin/sh was a lie, and when someone points that out, I
>>am embarassed and grateful, especially when the fix is really, really
>>easy.  I'm not "everybody", but then, not everybody's script starts
>>with a lie.  Just three of mine :-/
>
> So changing the shbang lines to read #!/bin/bash would suffice, no?
>
>   .andy
>
>
>>
>>-D.
>>_______________________________________________
>>SlackBuilds-users mailing list
>>SlackBuilds-users@...
>>http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>>Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>>FAQ - http://slackbuilds.org/faq/
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users@...
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>

--

-- 
Sent from my mobile device

You! What PLANET is this!
	-- McCoy, "The City on the Edge of Forever", stardate 3134.0
Ben Mendis | 2 Nov 05:27 2010
Picon

Re: Patch proposal to remove bashisms from some scripts



On Mon, Nov 1, 2010 at 9:07 AM, King Beowulf <kingbeowulf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I would say so.

My 2 cents: SBo hosts packages for Slackware. Slackware default shell
is bash. Slackbuild scripts should be bash compliant.  Anything else
is an exercise for the end user (eg dependency resolution etc).
 
Yes, the *default* shell is Bash, however not the _only_ shell. Having a default does not, IMHO, excuse you from following the standard.

It would be perfectly valid to say, "SBo expects a full Slackware Install. A full Slackware install includes /bin/bash. Therefore, all Slackbuild are allowed to begin with #!/bin/bash". And, in fact, I would prefer that they _do_ begin with /bin/bash if that was the only shell they were ever tested in.

However, I don't consider it valid to say, "SBo expects a full Slackware Install. In the *default* install 'sh' is a symlink to 'bash'. Therefore, all Slackbuilds are allowed to assume 'sh' and 'bash are the same thing." You are at the same time acknowledging the existence of other shells (and the fact that there are mechanisms in place to properly handle a multi-shell environment) and dismissing that fact as unimportant because it would require you to type two extra characters each time you wrote a Slackbuild.


Contrary to Mr. Beowulf, I think that, by default, we should comply with the standard and use #!/bin/bash for scripts that were written and tested with the assumption that they would be run in Bash. If someone wants to explicitly (rather than implicitly) run the script in a different shell, then we can leave THAT as an exercise to the individual user.


Speaking practically, however, I don't expect this to be enforced. It would create a disproportionate burden on all maintainers and the SBo admins to have to test that the correct shell is declared in the shebang. However I think it would be reasonable to make a note of suggestion in the template or on the submission page that Slackbuilds (like all shell scripts) that specify 'sh' are expected to conform to pure Bourne Shell, and that it is perfectly acceptable to specify 'bash' for you script instead.
<div>
<br><br><div class="gmail_quote">On Mon, Nov 1, 2010 at 9:07 AM, King Beowulf <span dir="ltr">&lt;<a href="mailto:kingbeowulf@...">kingbeowulf@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
I would say so.<br><br>
My 2 cents: SBo hosts packages for Slackware. Slackware default shell<br>
is bash. Slackbuild scripts should be bash compliant. &nbsp;Anything else<br>
is an exercise for the end user (eg dependency resolution etc).<br>
</blockquote>
<div>&nbsp;</div>
<div>Yes, the *default* shell is Bash, however not the _only_ shell. Having a default does not, IMHO, excuse you from following the standard. <br><br>It would be perfectly valid to say, "SBo expects a full Slackware Install. A full Slackware install includes /bin/bash. Therefore, all Slackbuild are allowed to begin with #!/bin/bash". And, in fact, I would prefer that they _do_ begin with /bin/bash if that was the only shell they were ever tested in.<br><br>However, I don't consider it valid to say, "SBo expects a full Slackware Install. In the *default* install 'sh' is a symlink to 'bash'. Therefore, all Slackbuilds are allowed to assume 'sh' and 'bash are the same thing." You are at the same time acknowledging the existence of other shells (and the fact that there are mechanisms in place to properly handle a multi-shell environment) and dismissing that fact as unimportant because it would require you to type two extra characters each time you wrote a Slackbuild.<br><br><br>Contrary to Mr. Beowulf, I think that, by default, we should comply with the standard and use #!/bin/bash for scripts that were written and tested with the assumption that they would be run in Bash. If someone wants to explicitly (rather than implicitly) run the script in a different shell, then we can leave THAT as an exercise to the individual user.<br><br><br>Speaking practically, however, I don't expect this to be enforced. It would create a disproportionate burden on all maintainers and the SBo admins to have to test that the correct shell is declared in the shebang. However I think it would be reasonable to make a note of suggestion in the template or on the submission page that Slackbuilds (like all shell scripts) that specify 'sh' are expected to conform to pure Bourne Shell, and that it is perfectly acceptable to specify 'bash' for you script instead. <br>
</div>
</div>
</div>
B Watson | 2 Nov 10:29 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On 11/2/10, Ben Mendis <dragonwisard@...> wrote:
> it is perfectly acceptable to specify 'bash' for you script instead.

It is? I'd always assumed that the "follow our templates whenever
possible" rule meant the #!/bin/sh (from the template) is required... If
it's allowed to say #!/bin/bash, I'll do that for all my future
submissions.

Maybe the admins could make a note of it on the submissions page, or
even change the template to start with #!/bin/bash (is there any reason
not to do this? My opinion is there's not, but I'm just a luser...)

Am not advocating mass-updating existing slackbuilds to change the
shebang line, mind. Just the template. Maybe with a comment saying
"do not change to #!/bin/sh unless you've actually tested your script
with at least ash and ksh"?

Pretty much a separate (possibly off-topic) question here: why would
anyone even care to use ash for /bin/sh on a build host? On an embedded
system it makes sense, but on the dev box where you build its packages?
Max Miorim | 2 Nov 14:11 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On Tue, Nov 2, 2010 at 7:29 AM, B Watson <yalhcru@...> wrote:
> On 11/2/10, Ben Mendis <dragonwisard@...> wrote:
>> it is perfectly acceptable to specify 'bash' for you script instead.
>
> It is? I'd always assumed that the "follow our templates whenever
> possible" rule meant the #!/bin/sh (from the template) is required... If
> it's allowed to say #!/bin/bash, I'll do that for all my future
> submissions.

Unless we're talking about using either /bin/bash or /bin/sh,  the
problem that I see with this is that it would open the precedence to
accept submissions of scripts using other shells like csh and zsh,
that could be a problem for the people that review the scripts, as
they'd have to learn the particularities of other shells - it could
slow down the process of review->approval considerably.

> Maybe the admins could make a note of it on the submissions page, or
> even change the template to start with #!/bin/bash (is there any reason
> not to do this? My opinion is there's not, but I'm just a luser...)
>
> Am not advocating mass-updating existing slackbuilds to change the
> shebang line, mind. Just the template. Maybe with a comment saying
> "do not change to #!/bin/sh unless you've actually tested your script
> with at least ash and ksh"?

I like the idea of updating the template. A note saying "you should
run these slackbuilds with bash" would be fine too. The current FAQ
and HOWTO assumes that the user know that Slackware assumes that
/bin/sh is a symlink to bash, that's a lot of assumptions if you ask
me. :)

> Pretty much a separate (possibly off-topic) question here: why would
> anyone even care to use ash for /bin/sh on a build host? On an embedded
> system it makes sense, but on the dev box where you build its packages?

Why not? It doesn't matters if my /bin/sh is maxsownsh, bash or ash,
the shebang denotes that the script is compatible with the bourne
shell and, as long as my shell is compatible with it, it should run
just fine. ;)

My motivation to change the shell was because a co-worker, which uses
Debian Sid, has the same hardware that I do and his notebook runs our
sh-compatible scripts considerably faster than mine.

We compared configurations/optimizations and did a quite exhaustive
research on gnu.bash.bug looking for performance regressions. Then, I
changed the shebang of these scripts to use /bin/ash and, mind you,
the same thing that took 16.702 seconds using bash as /bin/sh took
6.803 with ash and pretty much the same happens to every script that
we tested.

As I can't change every shebang or run the scripts using
"lightandfastsh script.sh", I did exactly what the others did in their
respective computers: changed my /bin/sh to a shell other than bash.

BTW, I don't have a "build host" - If the box that is building is slow
or if I just need more processing power, I use distcc.
B Watson | 2 Nov 20:30 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

On 11/2/10, Max Miorim <miorimmax@...> wrote:

> Unless we're talking about using either /bin/bash or /bin/sh,  the
> problem that I see with this is that it would open the precedence to
> accept submissions of scripts using other shells like csh and zsh,
> that could be a problem for the people that review the scripts, as
> they'd have to learn the particularities of other shells - it could
> slow down the process of review->approval considerably.

Yah, I hadn't thought about csh. Definitely agree the rule should be
/bin/bash, or /bin/sh for scripts that were tested with ash.

> the same thing that took 16.702 seconds using bash as /bin/sh took
> 6.803 with ash and pretty much the same happens to every script that
> we tested.

Interesting. Never even occurred to me to test performance, I expect
interpreters to be slow, and at least subconsciously I was aware that bash
is bloated... but wouldn't have guessed ash would be *that* much faster.

Hm. I just now thought I'd try a couple of things in ash, as an
interactive shell, on slack64 13.1, and the damn thing segfaulted halfway
through typing the first command. /me runs off to do some more testing...
JK Wood | 2 Nov 21:09 2010
Picon

Re: Patch proposal to remove bashisms from some scripts



On Tue, Nov 2, 2010 at 2:30 PM, B Watson <yalhcru <at> gmail.com> wrote:
On 11/2/10, Max Miorim <miorimmax-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Unless we're talking about using either /bin/bash or /bin/sh,  the
> problem that I see with this is that it would open the precedence to
> accept submissions of scripts using other shells like csh and zsh,
> that could be a problem for the people that review the scripts, as
> they'd have to learn the particularities of other shells - it could
> slow down the process of review->approval considerably.

Yah, I hadn't thought about csh. Definitely agree the rule should be
/bin/bash, or /bin/sh for scripts that were tested with ash.

> the same thing that took 16.702 seconds using bash as /bin/sh took
> 6.803 with ash and pretty much the same happens to every script that
> we tested.

Interesting. Never even occurred to me to test performance, I expect
interpreters to be slow, and at least subconsciously I was aware that bash
is bloated... but wouldn't have guessed ash would be *that* much faster.

Hm. I just now thought I'd try a couple of things in ash, as an
interactive shell, on slack64 13.1, and the damn thing segfaulted halfway
through typing the first command. /me runs off to do some more testing...

Certainly Bash is slower.  It supports a wider array of scripting options, after all.

Remember the golden rule of software:  You can have it fast, you can have it cheap, you can have it good.  Pick two.

(Note: Not saying ash is not good.  It just doesn't compare feature-wise to Bash, which is also free...)

--JK
<div>
<br><br><div class="gmail_quote">On Tue, Nov 2, 2010 at 2:30 PM, B Watson <span dir="ltr">&lt;<a href="mailto:yalhcru@...">yalhcru <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="im">On 11/2/10, Max Miorim &lt;<a href="mailto:miorimmax <at> gmail.com">miorimmax@...</a>&gt; wrote:<br><br>
&gt; Unless we're talking about using either /bin/bash or /bin/sh, &nbsp;the<br>
&gt; problem that I see with this is that it would open the precedence to<br>
&gt; accept submissions of scripts using other shells like csh and zsh,<br>
&gt; that could be a problem for the people that review the scripts, as<br>
&gt; they'd have to learn the particularities of other shells - it could<br>
&gt; slow down the process of review-&gt;approval considerably.<br><br>
</div>Yah, I hadn't thought about csh. Definitely agree the rule should be<br>
/bin/bash, or /bin/sh for scripts that were tested with ash.<br><div class="im">
<br>
&gt; the same thing that took 16.702 seconds using bash as /bin/sh took<br>
&gt; 6.803 with ash and pretty much the same happens to every script that<br>
&gt; we tested.<br><br>
</div>Interesting. Never even occurred to me to test performance, I expect<br>
interpreters to be slow, and at least subconsciously I was aware that bash<br>
is bloated... but wouldn't have guessed ash would be *that* much faster.<br><br>
Hm. I just now thought I'd try a couple of things in ash, as an<br>
interactive shell, on slack64 13.1, and the damn thing segfaulted halfway<br>
through typing the first command. /me runs off to do some more testing...<br><div>
<div></div>
<div class="h5">_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
</div>
</div>
</blockquote>
</div>
<br>Certainly Bash is slower.&nbsp; It supports a wider array of scripting options, after all.<br><br>Remember the golden rule of software:&nbsp; You can have it fast, you can have it cheap, you can have it good.&nbsp; Pick two.<br><br>(Note: Not saying ash is not good.&nbsp; It just doesn't compare feature-wise to Bash, which is also free...)<br><br>--JK<br>
</div>
Donald Allen | 2 Nov 21:15 2010
Picon

Re: Patch proposal to remove bashisms from some scripts



On Tue, Nov 2, 2010 at 3:30 PM, B Watson <yalhcru <at> gmail.com> wrote:
On 11/2/10, Max Miorim <miorimmax <at> gmail.com> wrote:

> Unless we're talking about using either /bin/bash or /bin/sh,  the
> problem that I see with this is that it would open the precedence to
> accept submissions of scripts using other shells like csh and zsh,
> that could be a problem for the people that review the scripts, as
> they'd have to learn the particularities of other shells - it could
> slow down the process of review->approval considerably.

Yah, I hadn't thought about csh. Definitely agree the rule should be
/bin/bash, or /bin/sh for scripts that were tested with ash.

> the same thing that took 16.702 seconds using bash as /bin/sh took
> 6.803 with ash and pretty much the same happens to every script that
> we tested.

Interesting. Never even occurred to me to test performance, I expect
interpreters to be slow, and at least subconsciously I was aware that bash
is bloated... but wouldn't have guessed ash would be *that* much faster.

Hm. I just now thought I'd try a couple of things in ash, as an
interactive shell, on slack64 13.1, and the damn thing segfaulted halfway
through typing the first command. /me runs off to do some more testing...

Yes, but it was really fast until it blew up ....

I've had the same experience in search of a less bloated browser than Firefox (really solid, reliable code of significant complexity is not so easy to come by). They all make sense, according to their developers, until you try to use them in real-life situations. 
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/


<div>
<br><br><div class="gmail_quote">On Tue, Nov 2, 2010 at 3:30 PM, B Watson <span dir="ltr">&lt;<a href="mailto:yalhcru@...">yalhcru <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
On 11/2/10, Max Miorim &lt;<a href="mailto:miorimmax@...">miorimmax <at> gmail.com</a>&gt; wrote:<br><br>
&gt; Unless we're talking about using either /bin/bash or /bin/sh, &nbsp;the<br>
&gt; problem that I see with this is that it would open the precedence to<br>
&gt; accept submissions of scripts using other shells like csh and zsh,<br>
&gt; that could be a problem for the people that review the scripts, as<br>
&gt; they'd have to learn the particularities of other shells - it could<br>
&gt; slow down the process of review-&gt;approval considerably.<br><br>
Yah, I hadn't thought about csh. Definitely agree the rule should be<br>
/bin/bash, or /bin/sh for scripts that were tested with ash.<br><br>
&gt; the same thing that took 16.702 seconds using bash as /bin/sh took<br>
&gt; 6.803 with ash and pretty much the same happens to every script that<br>
&gt; we tested.<br><br>
Interesting. Never even occurred to me to test performance, I expect<br>
interpreters to be slow, and at least subconsciously I was aware that bash<br>
is bloated... but wouldn't have guessed ash would be *that* much faster.<br><br>
Hm. I just now thought I'd try a couple of things in ash, as an<br>
interactive shell, on slack64 13.1, and the damn thing segfaulted halfway<br>
through typing the first command. /me runs off to do some more testing...<br>
</blockquote>
<div><br></div>
<div>Yes, but it was really fast until it blew up ....</div>
<div><br></div>
<div>I've had the same experience in search of a less bloated browser than Firefox (really solid, reliable code of significant complexity is not so easy to come by). They all make sense, according to their developers, until you try to use them in real-life situations.&nbsp;</div>
<blockquote class="gmail_quote">
_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
</blockquote>
</div>
<br>
</div>
TuxaneMedia | 6 Nov 11:27 2010

Re: Patch proposal to remove bashisms from some scripts

I think slackbuilds should read #!/bin/bash (and not sh or ash) for maximum safety and compatility.
It's  a 2 minute job for everyone the alter the script to build with ash (if it would build with ash or any other)
but it can't be the job of every maintainer to test building against all the  different shells.



Le 02.11.2010 21:15, Donald Allen a écrit :


On Tue, Nov 2, 2010 at 3:30 PM, B Watson <yalhcru-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On 11/2/10, Max Miorim <miorimmax-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Unless we're talking about using either /bin/bash or /bin/sh,  the
> problem that I see with this is that it would open the precedence to
> accept submissions of scripts using other shells like csh and zsh,
> that could be a problem for the people that review the scripts, as
> they'd have to learn the particularities of other shells - it could
> slow down the process of review->approval considerably.

Yah, I hadn't thought about csh. Definitely agree the rule should be
/bin/bash, or /bin/sh for scripts that were tested with ash.

> the same thing that took 16.702 seconds using bash as /bin/sh took
> 6.803 with ash and pretty much the same happens to every script that
> we tested.

Interesting. Never even occurred to me to test performance, I expect
interpreters to be slow, and at least subconsciously I was aware that bash
is bloated... but wouldn't have guessed ash would be *that* much faster.

Hm. I just now thought I'd try a couple of things in ash, as an
interactive shell, on slack64 13.1, and the damn thing segfaulted halfway
through typing the first command. /me runs off to do some more testing...

Yes, but it was really fast until it blew up ....

I've had the same experience in search of a less bloated browser than Firefox (really solid, reliable code of significant complexity is not so easy to come by). They all make sense, according to their developers, until you try to use them in real-life situations. 
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/


_______________________________________________ SlackBuilds-users mailing list SlackBuilds-users-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/

<div>
    I think slackbuilds should read #!/bin/bash (and not sh or ash) for
    maximum safety and compatility.<br>
    It's&nbsp; a 2 minute job for everyone the alter the script to build with
    ash (if it would build with ash or any other)<br>
    but it can't be the job of every maintainer to test building against
    all the&nbsp; different shells.<br><br><br><br>
    Le 02.11.2010 21:15, Donald Allen a &eacute;crit&nbsp;:
    <blockquote cite="mid:AANLkTi=iWko3ko+Bh+pAmmUiR8HFGzvwMZEBXCCK-JjS@..." type="cite">
<br><br><div class="gmail_quote">On Tue, Nov 2, 2010 at 3:30 PM, B Watson
        <span dir="ltr">&lt;<a moz-do-not-send="true" href="mailto:yalhcru@...">yalhcru@...</a>&gt;</span>
        wrote:<br><blockquote class="gmail_quote">
          On 11/2/10, Max Miorim &lt;<a moz-do-not-send="true" href="mailto:miorimmax@...">miorimmax@...</a>&gt;
          wrote:<br><br>
          &gt; Unless we're talking about using either /bin/bash or
          /bin/sh, &nbsp;the<br>
          &gt; problem that I see with this is that it would open the
          precedence to<br>
          &gt; accept submissions of scripts using other shells like csh
          and zsh,<br>
          &gt; that could be a problem for the people that review the
          scripts, as<br>
          &gt; they'd have to learn the particularities of other shells
          - it could<br>
          &gt; slow down the process of review-&gt;approval
          considerably.<br><br>
          Yah, I hadn't thought about csh. Definitely agree the rule
          should be<br>
          /bin/bash, or /bin/sh for scripts that were tested with ash.<br><br>
          &gt; the same thing that took 16.702 seconds using bash as
          /bin/sh took<br>
          &gt; 6.803 with ash and pretty much the same happens to every
          script that<br>
          &gt; we tested.<br><br>
          Interesting. Never even occurred to me to test performance, I
          expect<br>
          interpreters to be slow, and at least subconsciously I was
          aware that bash<br>
          is bloated... but wouldn't have guessed ash would be *that*
          much faster.<br><br>
          Hm. I just now thought I'd try a couple of things in ash, as
          an<br>
          interactive shell, on slack64 13.1, and the damn thing
          segfaulted halfway<br>
          through typing the first command. /me runs off to do some more
          testing...<br>
</blockquote>
        <div><br></div>
        <div>Yes, but it was really fast until it blew up ....</div>
        <div><br></div>
        <div>I've had the same experience in search of a less bloated
          browser than Firefox (really solid, reliable code of
          significant complexity is not so easy to come by). They all
          make sense, according to their developers, until you try to
          use them in real-life situations.&nbsp;</div>
        <blockquote class="gmail_quote">
          _______________________________________________<br>
          SlackBuilds-users mailing list<br><a moz-do-not-send="true" href="mailto:SlackBuilds-users@...">SlackBuilds-users@...</a><br><a moz-do-not-send="true" href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
          Archives - <a moz-do-not-send="true" href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
          FAQ - <a moz-do-not-send="true" href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
</blockquote>
      </div>
      <br>

_______________________________________________
SlackBuilds-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SlackBuilds-users@...">SlackBuilds-users@...</a>
<a class="moz-txt-link-freetext" href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a>
Archives - <a class="moz-txt-link-freetext" href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a>
FAQ - <a class="moz-txt-link-freetext" href="http://slackbuilds.org/faq/">http://slackbuilds.org/faq/</a>

    </blockquote>
    <br>
</div>
Ben Mendis | 2 Nov 14:31 2010
Picon

Re: Patch proposal to remove bashisms from some scripts


On Tue, Nov 2, 2010 at 5:29 AM, B Watson <yalhcru-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Pretty much a separate (possibly off-topic) question here: why would
anyone even care to use ash for /bin/sh on a build host? On an embedded
system it makes sense, but on the dev box where you build its packages?

A counter argument might be, why should we preclude the ability to build packages on the system where they are to be deployed?

Slackware has an official ARM port now and while ARM is getting faster, you might still want to run with a lighter-weight shell to conserve memory or improve performance.

I'm no authority on the matter, but my impression is that it's very "un-Slackware" to dictate that users must conform to an arbitrary default. Especially when that would violate the standard.


As far as opening up submissions to other shells, I agree that could become an issue. Perl and Python are also in the default Slackware install but I don't wish to see SlackBuilds written in those languages on SBo. I'm not in a position to set policy but I would suggest that our benevolent admins accept either /bin/bash or /bin/sh, with the polite request that /bin/sh should be used _only_ if it has been tested in another Bourne-compliant shell like ash. I think that is reasonable.
<div>
<br><div class="gmail_quote">On Tue, Nov 2, 2010 at 5:29 AM, B Watson <span dir="ltr">&lt;<a href="mailto:yalhcru@...">yalhcru@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<br>
Pretty much a separate (possibly off-topic) question here: why would<br>
anyone even care to use ash for /bin/sh on a build host? On an embedded<br>
system it makes sense, but on the dev box where you build its packages?<br>
</blockquote>
<div>
<br>A counter argument might be, why should we preclude the ability to build packages on the system where they are to be deployed?<br><br>Slackware has an official ARM port now and while ARM is getting faster, you might still want to run with a lighter-weight shell to conserve memory or improve performance.<br><br>I'm no authority on the matter, but my impression is that it's very "un-Slackware" to dictate that users must conform to an arbitrary default. Especially when that would violate the standard. <br><br><br>As far as opening up submissions to other shells, I agree that could become an issue. Perl and Python are also in the default Slackware install but I don't wish to see SlackBuilds written in those languages on SBo. I'm not in a position to set policy but I would suggest that our benevolent admins accept either /bin/bash or /bin/sh, with the polite request that /bin/sh should be used _only_ if it has been tested in another Bourne-compliant shell like ash. I think that is reasonable. <br>
</div>
</div>
</div>
Manuel Reimer | 2 Nov 21:14 2010
Picon

Re: Patch proposal to remove bashisms from some scripts

Max Miorim wrote:
> Recently I have been tinkering with one of my boxes to use ash as
> /bin/sh and noticed that doing so some SlackBuilds aren't working as
> intended anymore.

Should fail. Slackware's init scripts also use bashism...

For example /etc/rc.d/rc.inet1 uses arrays, which are not standardized.

Some time ago, I planned to try how fast Slackware would boot up with a 
faster shell, but failed with those scripts.

Yours

Manuel


Gmane