FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu User

 
 
LinkBack Thread Tools
 
Old 02-23-2012, 01:03 PM
CJ Tres
 
Default running a simple command line tool

On 02/23/2012 05:35 AM, Steve Flynn wrote:

On 23 February 2012 11:16, CJ Tres<ctres@grics.net> wrote:


Running basic smoketest.
smoketest.sh: 12: [[: not found
smoketest.sh: 18: [[: not found
smoketest.sh: 26: function: not found
Error found. Leaving run.11199 in place.
Unable to execute command: 'sh test.sh'



These errors are coming from smoketest.sh shell script - it's
basically saying that the shell the script is running under doesn't
support [[ and ]] as test commands.

Have a look at the first line of this script - it'll begin with a hash
bang (#!) followed by the name of the shell which should be used to
interpret the script.

What does it say?



These are the first lines of smoketest.sh

# This script is a simple regression test for basic natool operations
# that don't create the database.

set -e

export NATOOL_NEUROS_PATH="$1"

if [[ ! -d $NATOOL_NEUROS_PATH ]]; then
echo "Invalid neuros path: '$NATOOL_NEUROS_PATH'"
exit 1
fi

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-23-2012, 01:21 PM
CJ Tres
 
Default running a simple command line tool

On 02/23/2012 05:40 AM, Avi Greenbury wrote:

CJ Tres wrote:


Running basic smoketest.
smoketest.sh: 12: [[: not found
smoketest.sh: 18: [[: not found
smoketest.sh: 26: function: not found
Error found. Leaving run.11199 in place.
Unable to execute command: 'sh test.sh'


This looks like it's down to a naughty developer

[[ is a 'bashism' (so-called because it's something that exists in
bash but not in the 'sh' that it's a development from).

The command 'sh test.sh' passes the 'test.sh' script to 'sh' which is
a shell. Normally and historically it's a link to /bin/bash but
modern Ubuntus and Debians use dash instead (in the interests of
speed). [[ doesn't work in dash, so the test script fails on that error
and the install aborts.



Running echo $SHELL returns /bin/bash on this install - Natty.
Can't remember for sure but I may have changed the default since I was
only just getting familiar with bash.




It should be a simple fix - the invocation of that script should be

bash test.sh

rather than

sh test.sh


So... a question.
From my obvious lack of knowledge, would an understanding of bash
scripting help shed some light on my darkness in this case, or is it
perl I would need to better understand?


Of scripting, bash would be more helpful here. Perhaps most useful
would be experience installing Perl apps, but that's rather niche

Really, this is less bash scripting and more simply using bash, but the
easiest way to use bash is to automate it into scripts.



The man page mentions that. I plan to write something (eventually) to
simplify running it - once I figure out what I need to know to do it.



--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-23-2012, 03:12 PM
Avi Greenbury
 
Default running a simple command line tool

CJ Tres wrote:
> On 02/23/2012 05:40 AM, Avi Greenbury wrote:
> > CJ Tres wrote:
> >
> >> Running basic smoketest.
> >> smoketest.sh: 12: [[: not found
> >> smoketest.sh: 18: [[: not found
> >> smoketest.sh: 26: function: not found
> >> Error found. Leaving run.11199 in place.
> >> Unable to execute command: 'sh test.sh'
> >
> > This looks like it's down to a naughty developer
> >
> > [[ is a 'bashism' (so-called because it's something that exists in
> > bash but not in the 'sh' that it's a development from).
> >
> > The command 'sh test.sh' passes the 'test.sh' script to 'sh' which
> > is a shell. Normally and historically it's a link to /bin/bash but
> > modern Ubuntus and Debians use dash instead (in the interests of
> > speed). [[ doesn't work in dash, so the test script fails on that
> > error and the install aborts.
>
>
> Running echo $SHELL returns /bin/bash on this install - Natty.

Yeah, that's the default shell for your user. /bin/bash should always
be bash, the iffy bit is where /bin/sh goes. It used to go to the
bourne shell, before bash (the 'bourne again' shell, it's successor)
was written. After that, it became common to make /bin/sh simply a link
to /bin/bash since bash's features are a superset of the bourne shell's
- something expecting the bourne shell will work in bash.

A few releases of Debian (and so Ubuntu) ago, it was agreed
that /bin/sh would instead be a link to dash, which is a good deal
smaller than bash. It's still a superset of the bourne shell, so
anything that only requires the bourne shell will still work, but it's
a different, and smaller, superset than bash.

The problem is that a lot of people had come to assume that /bin/sh was
bash, not the bourne shell, and when you try to run something that's
got bashisms that are not present in dash (like the '[[' construct) in
dash you get a syntax error.

The error message tells you what command was run:
Unable to execute command: 'sh test.sh'

So, we can find out what's run when we execute 'sh':
root@donkey:~# which sh
/bin/sh
root@donkey:~# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2011-05-03 16:04 /bin/sh -> dash
root@donkey:~#

And you can see that it's a symlink to dash (that's what the '->' syntax
means - the fact it just says 'dash' means it's in the same directory,
so /bin/dash).

Now, you *could* bodge it by repointing that symlink, but that's not a
great idea in case things call that expecting dashisms that aren't in
bash. What *should* happen is that when a script needs bash it is passed
to bash, not sh. This is something that should really be fixed in those
test scripts in that installer.

--
Avi

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-23-2012, 03:52 PM
CJ Tres
 
Default running a simple command line tool

On 02/23/2012 10:12 AM, Avi Greenbury wrote:



And you can see that it's a symlink to dash (that's what the '->' syntax
means - the fact it just says 'dash' means it's in the same directory,
so /bin/dash).

Now, you *could* bodge it by repointing that symlink, but that's not a
great idea in case things call that expecting dashisms that aren't in
bash. What *should* happen is that when a script needs bash it is passed
to bash, not sh. This is something that should really be fixed in those
test scripts in that installer.



Thanks for the info. I'll leave it to the "naughty dev" to fix then.
Glad it's not just me being ignorant.

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-23-2012, 04:40 PM
Johnny Rosenberg
 
Default running a simple command line tool

2012/2/23 Avi Greenbury <lists@avi.co>:
> CJ Tres wrote:
>> On 02/23/2012 05:40 AM, Avi Greenbury wrote:
>> > CJ Tres wrote:
>> >
>> >> Running basic smoketest.
>> >> smoketest.sh: 12: [[: not found
>> >> smoketest.sh: 18: [[: not found
>> >> smoketest.sh: 26: function: not found
>> >> Error found. *Leaving run.11199 in place.
>> >> Unable to execute command: 'sh test.sh'
>> >
>> > This looks like it's down to a naughty developer
>> >
>> > [[ is a 'bashism' (so-called because it's something that exists in
>> > bash but not in the 'sh' that it's a development from).
>> >
>> > The command 'sh test.sh' passes the 'test.sh' script to 'sh' which
>> > is a shell. Normally and historically it's a link to /bin/bash but
>> > modern Ubuntus and Debians use dash instead (in the interests of
>> > speed). [[ doesn't work in dash, so the test script fails on that
>> > error and the install aborts.
>>
>>
>> Running echo $SHELL returns /bin/bash on this install - Natty.
>
> Yeah, that's the default shell for your user. /bin/bash should always
> be bash, the iffy bit is where /bin/sh goes. It used to go to the
> bourne shell, before bash (the 'bourne again' shell, it's successor)
> was written. After that, it became common to make /bin/sh simply a link
> to /bin/bash since bash's features are a superset of the bourne shell's
> - something expecting the bourne shell will work in bash.
>
> A few releases of Debian (and so Ubuntu) ago, it was agreed
> that /bin/sh would instead be a link to dash, which is a good deal
> smaller than bash.

I wonder why they did that. Why not just include sh and use it as is?
If someone want to use dash, include that too. How hard can it be to
type ”#! /bin/dash”?
Is sh so extremely big that there is a point to not include it in the
distribution?


Kind regards

Johnny Rosenberg
ジョニー・*ーゼンバーグ

> It's still a superset of the bourne shell, so
> anything that only requires the bourne shell will still work, but it's
> a different, and smaller, superset than bash.
>
> The problem is that a lot of people had come to assume that /bin/sh was
> bash, not the bourne shell, and when you try to run something that's
> got bashisms that are not present in dash (like the '[[' construct) in
> dash you get a syntax error.
>
> The error message tells you what command was run:
> *Unable to execute command: 'sh test.sh'
>
> So, we can find out what's run when we execute 'sh':
> root@donkey:~# which sh
> /bin/sh
> root@donkey:~# ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 2011-05-03 16:04 /bin/sh -> dash
> root@donkey:~#
>
> And you can see that it's a symlink to dash (that's what the '->' syntax
> means - the fact it just says 'dash' means it's in the same directory,
> so /bin/dash).
>
> Now, you *could* bodge it by repointing that symlink, but that's not a
> great idea in case things call that expecting dashisms that aren't in
> bash. What *should* happen is that when a script needs bash it is passed
> to bash, not sh. This is something that should really be fixed in those
> test scripts in that installer.
>
> --
> Avi

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-23-2012, 06:08 PM
Avi Greenbury
 
Default running a simple command line tool

Johnny Rosenberg wrote:
> > A few releases of Debian (and so Ubuntu) ago, it was agreed
> > that /bin/sh would instead be a link to dash, which is a good deal
> > smaller than bash.
>
> I wonder why they did that. Why not just include sh and use it as is?
> If someone want to use dash, include that too. How hard can it be to
> type ”#! /bin/dash”?
> Is sh so extremely big that there is a point to not include it in the
> distribution?

Even if /bin/sh was the stripped-down posix shell it's supposed to be,
it'd still only be a stripped-down posix shell and unable to perform
any bash-specific features.

The argument with where /bin/sh goes is that if you're explicitly
asking for /bin/sh (as the test script we're talking about does) you
can only reasonably be expecting sh, so it can point to anything that
provides the totality of what sh does, which includes dash.

The only scripts that break are where someone's done something stupid
like asking for one interpreter and then coding for another.

--
Avi.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 04:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org