can't execute shell scripts

have exactly the same problem.

bash: ./configure: /bin/sh: bad interpreter: Permission denied

ubuntu 14.10 (r133)

I remounted / so that it becomes writeable ('sudo mount -o remount,rw /') and then copied my programs/scripts to e.g. /opt and ran them there. Note: / does not have much free space left on my device (~350MB). I'm not sure why it works and if this is the proper way of doing this (I don't think so: There has to be a reason why 'phablet-config writable-image' disables over-the-air-updates).

The permissions of /opt are drwxr-xr-x

Bash Reference Manual
_____________________________________________________
Reference Documentation for Bash
Edition 4.2, for Bash Version 4.2. December 2010

Chet Ramey, Case Western Reserve University
Brian Fox, Free Software Foundation
.
.
.

4 Shell Builtin Commands
.
.
.

4.1 Bourne Shell Builtins

The following shell builtin commands are inherited from the
Bourne Shell. These commands are implemented as specified
by the posix standard.

: ( a colon)

                             : [ arguments ]

               Do nothing beyond expanding arguments and
               performing redirections.
               The return status is zero.

. ( a period)

                            . filename [ arguments ]

               Read and _execute_ commands from the filename
               argument in the current shell context.

               If filename doesnot contain a slash, the PATH variable
               is used to find filename.
               When Bash is not in posix mode, the current directory
               is searched filename is not found in $PATH.
               If any arguments are supplied, they become the
               positional parameters when file name is executed.
               Otherwise the positional parameters are unchanged.
               The return status is the exit status of the last command
               executed, or zero if no commands are executed.
               If file name is not found, or cannot be read, the return
               status is non-zero.
               This built in is equivalent to source.

***** *****
***** SINCE YOU DIDN'T TELL us readers what you *****
***** actually entered at the command line, we *****
***** can only presume. *****
***** *****
***** *****
***** Based on that bit of BASH that I gave, *****
***** *****
***** you should have typed in this: *****
***** *****
***** *****
***** *****
***** *****
***** . ./myscript *****
***** *****
***** *****
***** *****
***** *****
***** The __ .__ is a command ! *****
***** That's right, just a period ! ...

Well that didn't show up well on this system.
I'll try again, but system will strip all extra(<humph>) spaces again.

$ . ./myscript

Be sure to "Read more" or "Download full txt" of my first comment.

The dratted PDF gives a closer resemblance to my desired format, but still is not perfect.

Thanks, the command you suggested worked! Thanks a lot for further explaining why things are as they are.

What surprises me is that I always ran "./myscript" on my computer and it was executed as I expected it. Furthermore, it seems that a lot of beginner tutorials suggest to just run "./myscript". Do you know why this is the case?

I read through my ~.bashrc file but could not find anything that seems to be related to this...

I've only just joined the Ubuntu One world for the
purpose of helping YOU slap your palm against your
forehead.

So I know nothing of your software or operating
systems or Projects. Please forgive me for not yet snooping
around this "place" enough yet.
____________________________________________________________________

You should obtain a copy of
"The UNIX Programming Environment"
by Brian W. Kernighan and Rob Pike.

Study of this should fulfill several credits of both History and
Computer Science coursework. <grin>

____________________________________________________________________

Existing in your $HOME directory should be the
HIDDEN FILES: .bashrc, .inputrc, and .init
( ls -a should reveal them)

In the file .init you should find a line similar to this:

export PATH=$HOME/bin:$HOME/local/bin:
$HOME/android-gcc-4.4.0/bin:
$HOME/system/bin:$HOME/system/bin/bbdir:

At some point I transferred something probably called
android-gcc-4.4.0.tar.gz
into my Unix-like world and used tar -z to untar it.
The tar command created the android-gcc-4.4.0 directory
and numerous subdirectories and filled them with all the
files required for proper enjoyment of android-gcc.

I chdir'ed ( cd ) to the android-gcc-4.4.0 directory and used the
"make" command. This command added the words
$HOME/android-gcc-4.4.0/bin: to the "PATH statement"
in the file .init ( as well as performed other tasks involved
in the complete installation of this software ) .

At some point I added my own directory "bbdir" to my world and
since I wanted all of my "commands" in it to be executable from
anywhere I added :$HOME/system/bin/bbdir: to the PATH
statement in the .init file.

Now, whatever tutorial that you use MAY assume that
the directory that they THINK you will be working in
has already been added to the $PATH.

( Caveat: I seem to almost remember another step to take
required to ensure executability. < sigh > But try this! )

I see, I'll simply add "$HOME/path/to/my/scripts" to my .init file. Thanks for the book recommendation, according to a description I read it sounds very interesting!

Thanks again for and your patience and for taking your time to explain this very clearly to me. I'm rather new to this topic and thought that it would be a bug since it didn't work like in the computer edition of Ubuntu...

I'm a bit curious - how did you find this bugreport?

>>>

I'm a bit curious - how did you find this bugreport?

I have pored endlessly over my Google History and I can't
find whatever combination of simple words brought your
bug to my screen.

Probably the words "execute" "shell" "scripts" were what
I searched.

"Ubuntu" __was__ really a rather rare topic for me.

_____________________________________________________________________________

I've also given my two cents worth in Bug #1365602

Ah, I see.

Thanks a lot!

Now this is strange: to find out if it works I simply ran "PATH=$PATH:$HOME/Scripts" and when I entered "testscript" I still get "bash: /home/phablet/Scripts/testscript: /bin/sh: bad interpreter: Permission denied".

Maybe it has something to do with the mount options? I'll add some information about this to my report.

You should have typed in:

export PATH=$HOME/bin:$HOME/local/bin:$HOME/Scripts/bin:$HOME/system/bin:

ALL of these "paths" must be found in the PATH

statement, or the system won't work correctly.

( Note:

Leftmost path is searched first. : : : Rightmost

path is searched last.)

The error

"bash: /home/phablet/Scripts/testscript: /bin/sh: bad interpreter: Permission denied"

shows that the system was not directed by

$PATH to search "/bin" ( in root ) for "/bin/sh".

( "/sh" is the default "shell".

Calls to /sh should be redirected

to "~/bash" by the line

"export SHELL= . . . /bash"

in .bashrc ( or in .bash_profile ).)

(( Our friend, the "." calls /sh to execute our

scripts. But /sh in turn calls our actual

_choice_ of shells--bash ))

((( The file .bashrc is executed by

interactive shells.

The file .bash_profile is executed by

login shells.

I don't have super user access to root,

nor do I "login", so my hands-on-knowledge

of .bash_profile is nil. )))

The typing these lengthy PATH statements on

the command line is prone to error, so we have

all these "initial" files.

( Although a _modern_ system does allow us to

paste pre-edited lines to the prompt with ease. )

I recommend that you save an original copy

of .init under a name such as .init0 ,

and then alter the .init file.

Now,

KEEP YOUR FINGERS OUT

OF THE .init0 FILE ! ! ! <grin>

"Simply" running a new PATH at the command

line is rarely actually simple.

(Note: __I__ very rarely "mount" anything. )

_________________________________________________

On MY android system, my choice of

TerminalIDE ( by Spartacusrex ) is stored in the

/data/data/com.spartacusrex.spartacuside/files/

directory.

So Spartacusrex has included these items in the

.bashrc file:

          export IDESYSTEM=$HOME/system

          export SHELL=$IDESYSTEM/bin/bash

Thus "/sh" points to

/data/data/com.spartacusrex.spartacuside/files/bin/bash

through the use of "export SHELL= . . ." .

I reinstalled Ubuntu on my device to make sure that this bug does not occur on my specific installation only. After the installation it seems that there is no ~/.init file by default in my home directory. Also, the PATH variable is neither specified in ~/.bashrc nor in ~/.profile (a comment in this file states that this file will be executed by a login shell if ~/.bash_profile and ~/.bash_login do not exist (which is the case)).

However, the default content of my PATH variable should be "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" (without quotes) : After a quick-and-dirty search for the string "PATH" in /etc ('grep PATH /etc/*') I found out that the PATH variable is specified in /etc/login.defs (the first comment in this file is "/etc/login.defs - Configuration control definitions for the login package.") on my system.

When I ran "PATH=$PATH:$HOME/Scripts" it actually added my path as I expected to the PATH variable: When I ran "echo $PATH"
 I got "/usr/share/click/preinstalled/.click/users/@all/com.ubuntu.terminal/lib/arm-linux-gnueabihf/bin:/usr/share/click/preinstalled/.click/users/@all/com.ubuntu.terminal:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/phablet/Scripts".
I think the beginning of PATH is specified by the terminal-app; it includes my path at the end ("/home/phablet/Scripts").

I know that you know a lot more than I do in this topic, but are you sure that I should type "export PATH=$HOME/bin:$HOME/local/bin:$HOME/Scripts/bin:$HOME/system/bin:"? I mean, I do not even have those paths in my home directory...
Anyway, if I run this command I get a "command not found"-message by many commands (such as ls: "-bash: ls: command not found") afterwards. (I guess that is because of different paths on my system...)

Since I do not have bash in my '/' directory I assumed that I should change the variable to ". . . /bin/bash" by running 'export SHELL=". . . /bin/bash" ' (note: when I ran 'export SHELL= . . . /bin/bash' I got an error for every string seperated by a space, e.g. "bash: export: `.': not a valid identifier").
However, this did not change anything - I still get the same error message...

The following

"export PATH=$HOME/bin:$HOME/local/bin:$HOME/Scripts/bin:$HOME/system/bin:"

is based on the example of MY system since I didn't have you actual PATH statement

before me.

-

The Instruction "PATH=$PATH:$HOME/Scripts" is what I should have given in the first

place. I am still hurriedly dusting-off many things in the back closet of my mind.

Oops, I used bad tactics.

-

In my phrase "export SHELL= . . . /bash",

the " . . . " was meant to be percieved as an

elipse representing an undetermined path.

( I very often use elipses in my non-technical

keyboard ramblings.)

-

Let me try this again:

export SHELL=/this/path/to/bash

-

<bent at the waist, head near knees,

arms held horizontally> He says,

"Oh, many apologies ( future (?) ) Great One !"

_________________________________________________________________

Elipses--from mathematical background ?
Deep nesting of parentheses--from study of LISP !
The use of "<" and ">" to enclose proposed
physical actions--from theater class.

Ok, thanks, now I understand what you wanted me to try.

With $PATH and $SHELL set as you told me it still does not seem to work for me...

(you are being very sarcastic or at least metaphoric in your second-to-last paragraph, right? (I am not good at detecting sarcasm even in my native language, sorry... (by the way, I _love_ parantheses! I should eventually have a look at LISP)))

That was an overly FLAMBOYANT display of my grief
at having wronged you.

I was saying that you may ( hopefully ) one day attain
the title "Great One" or you may ( unknownst to me)
already hold it.

No sarcasm intended.
No _obvious_ metaphor.

syntax error - poorly constructed if-then-else statement

-- "Virklich, das tut mir leid!" --
____________________________________________________

Oh, great, _now_ my memory disgorges this !

***** In recent years , Ubuntu _boots_ *****

***** using "Dash" rather than "Bash". *****

This suggests a different directory path name, and likely

not .bashrc as an initial file ( at system boot ).

-

Many Android apps come with "BusyBox" incorporated into

the package just to make life easier for us "command line"

junkies, and I _don't_ doubt that Ubuntu has BusyBox ( and

therefore Bash ) onboard for possible invocation by users.

-

( Dash, _if_ it is virtually the same as NetBSD ASH, comes

equipped only with the "dd" built-in-command and not the

more familiar "cp" built-in-command. This is a strong

selling point for Bash. <grin> )

-
__________________________

dash(1) - Linux man page
__________________________

 -

. . . A login shell first reads commands from the files

          /etc/profile and

         .profile if they exist.

If the environment variable ENV

          is set on entry to an interactive shell, or

          is set in the .profile of a login shell,

the shell next reads commands

from the file named in ENV.

-

Therefore, a user should place commands that are to be

executed only at login time in the .profile file, and commands

that are executed for every interactive shell inside the ENV file.

-

To set the ENV variable to some file,

place the following line in your .profile of your home directory

ENV=$HOME/.shinit; export ENV

substituting for ''.shinit'' any filename you wish.

-

If command line arguments besides the options have been

specified, then the shell treats the first argument as the

name of a file from which to read commands (a shell script),

and the remaining arguments are set as the

positional parameters of the shell ($1, $2, etc). Otherwise,

the shell reads commands from its standard input.

Ok, thanks for clarification. Don't worry, nothing broke and I learned more about my system. (I like learning things about my system, especially when nothing breaks - I think the way how the parts work (together) is very interesting)

I have been called something similar to "Great One" by some of my friends for doing things like installing drivers on a windows system (those installations where one has to download the driver and then press install (not really a glorious thing...)).
Maybe, if I'll learn a lot and gain more experience I might be called like this for something that is really great :-)

Wow, you know german! (I've heard that it is not easy to learn german when your native language isn't german)
_____________________

As I understood BusyBox by reading the article in the english Wikipedia it seems to me that BusyBox is one package that has a lot of commands integrated in it. However, I think that Ubuntu doesn't have this included but has all programs in directories like /bin, /usr/bin and so on - I mean, there is a single executable for every single program, e.g. in /bin there are executables like bash, cat, date, gzip and so on. All programs that are run in userspace are in those directories.
_____________________

So according to your last paragrapgh I should be able to run a shell script by just entering the path to the file in dash, right?
(If so, it seems that it does not work when I run dash interactively, I get "dash: 1: Scripts/testscript: Permission denied")

Remember that a script written using the protcols of Bash

may call for the shell to do things that Dash can't interpret

properly.

The message:

          "dash: 1: Scripts/testscript: Permission denied"

suggests to me that your script may have bombed because

of something in line no. 1 that Dash couldn't do.

_______________________________________________________________

You should probably research the command "chsh".

This will do automatically what we've just

be trying to do by hand--alter initial files.

Bash has it.

But you should seek to use the Dash version

( if indeed that is the shell you boot in ).

The Dash version ( as configured for you system )

theoretically would know the the names of the

files that need changes.

I found out a few things:

It seems that I called dash in a wrong way:
whenever I enter a nonexisting command I get "dash: <n>: not found" where <n> is the number of how many commands I have already entered in this session. So in my case "dash: 1: Scripts/testscript: Permission denied" just means that it can't be executed and that it is the first command I ran...

Before trying to use chsh I'd like to mention that I found out another thing:
my actual home directory (which lies in "/userdata/user-data/phablet/") is only mounted to "/home". When I cd to this directory I am able to run my scripts in bash and in dash (when I call them using ". ./testscript" or when I use "./testscript"). This path is neither specified in $PATH nor is it in any other environment variable except PWD (this makes sense to me) (I used "printenv | grep user-data").

So it has to have something to do with the mount options of my home directory.
("/userdata/user-data /home none bind 0 0" in my /etc/fstab means that the contents of "/userdata/user-data/" are mounted to "/home" if I understood everything correctly)

It also seems that my /etc/fstab file is mounted as tmpfs and it always changes back to its original state on a reboot.

From "Changing your Login Shell"
_____________________________________________________

The correct way for a user to change his or her shell
is via the chsh command.

chsh stands for change shell,
and does exactly what the name suggests.

Invoke it with no arguments and you will be prompted
for your password, then you will be prompted for your shell.

The file /etc/shells is consulted, and your chosen shell must
be included in there for your change to be accepted. If you
enter the name of a binary which is not contained in
/etc/shells you'll receive and error similar to this:

From: "Why doesn’t my /bin/sh script run under Ubuntu?"
___________________________________________________________

In Ubuntu 6.10 (known as Edgy Eft) the decision was made
to replace the Bourne Again Shell (bash) with the Debian
Almquist Shell (or dash) as /bin/sh in Ubuntu.

-

To undo this change by the Ubuntu team, one can do this:
-
sudo dpkg-reconfigure dash
-
When this command executes, specify that you do not
want dash to act as /bin/sh. This will make every script
that runs /bin/sh run bash as has traditionally been the
case.
-
You can also make your scripts run /bin/bash instead of
/bin/sh; this provides all of the bash capabilities without
any concern as to whether /bin/sh will change again.

So you are interested in Lisp ?

-

Lisp has in its programming commands something

called a "lamda" ( a nameless _function_).

-

So the _greek_letter_ lambda is often the featured

graphic on a number of software packages.

-

Early on, Lisp forked into two principal divisions:

Common Lisp and Scheme

-

Scheme has then forked into such names as:

Gambit, Guile, and Clojure

 -

And so my story brings me to . . .

-

________________________________

guile(1) - Linux man page
________________________________

-

Name

guile - a Scheme interpreter

-

Synopsis

-

guile [-q] [-ds] [--help] [--version] [--emacs] [--debug]
[-l FILE] [-e FUNCTION] [] [-c EXPR] [-s SCRIPT] [--]
Description

-

GNU Guile is an interpreter for the Scheme programming
language. It implements R5RS, providing additional features
necessary for real-world use. It is extremely simple to embed
guile into a C program, calling C from Scheme and Scheme
from C. Guile's design makes it very suitable for use as an
"extension" or "glue" language, but it also works well as a
stand-alone scheme development environment.

-

The guile executable itself provides a stand-alone interpreter
for scheme programs, for either interactive use or executing
scripts.

-

This manpage provides only brief instruction in invoking guile
from the command line. Please consult the guile info
documentation (type info guile at a command prompt) for
more information. There is also a tutorial (info guile-tut)
available.

 -
-
-

The story gets more interesting when we see where

guile is available . . .

-

____________________________________________________

Ubuntu Manpage: guile - a Scheme interpreter
manpages.ubuntu.com/manpages/dapper/man1/guile.1.html

____________________________________________________

-

So in addition to writing scripts in ash, bash, awk, and sed,

your system may already be ready for you to write scripts

in guile <-- scheme <-- lisp .

-

Now, are you really, really _certain_ that you want to learn lisp ? ? ? ! ! ! ! !

So I changed /bin/sh to /bin/bash and I still get the same error.
Changing my login shell should not affect anything else but my terminal, right? So programs that are executed as my user won't be effected? If so I'll try to change my shell.

Ok, Lisp sounds interesting to me but I think I should get more experienced in C before.
(Thanks for the pointer to guile; it is not installed by default but it could be installed easily).

Once you are logged in ? Nope.

_________________________________________

More experienced in "C" ? Well, perhaps after creating

your own Unix clone, you would feel that you could claim

to be experienced . . . .

Learn Lisp first, it's infinitely easier.

You CAN teach yourself Lisp ! ( I did. )

"C" is not for the faint of heart. You can expect to take

several university courses just so you can call yourself

a beginner.

-

All I've ever taken in "C" programming is a single

three month university course ( one complete

school term ).

-

I think I could still succeed at following through

the with the logic of someone else's programming.

But I now cringe to think of writing a worthwile

program of my own from scratch.

( Does this exhibit the "Use it or Lose it" principle ? )

-

Allow me to make this comparison: My German

instructor promised the class, "Some day I'll learn

Spanish--when I have a weekend free." The relative

difficulty of German compared to Spanish is the

same as that of "C" compared to Lisp.

-

Use Lisp to relax as you sweat out the "C" .

( You'll need something to do while you

    COMPILE your "C" programs. )

-

Clojure is a Scheme that can convert its code to Java.

Gambit-C is a Scheme that can convert its code to "C".

( So you can avail yourself of coding examples

   "written by the experts". )

-

________________What___?_____________

-

Launchpad has Gambit-C as one of the

projects it's working On ?

-

Dude, I'm so sorry.

You just became a Guinea Pig.

I previously said:

"Clojure is a Scheme that can convert its code to Java."

Please allow me to recant.

-

Clojure is a Scheme that is _implemented_ in Java.

"Clojure is a dynamic programming language that
targets the Java Virtual Machine (and the CLR, and
JavaScript). It is designed to be a general-purpose
language, combining the approachability and
interactive development of a scripting language
with an efficient and robust infrastructure for
multithreaded programming. Clojure is a compiled
language - it compiles directly to JVM bytecode,
yet remains completely dynamic. Every feature
supported by Clojure is supported at runtime.
Clojure provides easy access to the Java
frameworks, with optional type hints and type
inference, to ensure that calls to Java can
avoid reflection."

( Hey, let's see YOU sum that up in

eleven words ! )

________________What___?_____________

-

Launchpad has Gambit-C as one of the

projects it's working On ?

-

Dude ! ! !
-
I am __so__ sorry !
-
You just became a Guinea Pig.

Ok, I'll try to change my shell then
_______________________________

Ah, I see, I should have said "get a very little bit known to C (not a beginner yet, but knowing the very basics such as e.g. a bit of the syntax)".
But what about learning C by myself? I mean, would I be a beginner if I understood everything from the book "Programming in C" (the one written by Brian Kernighan and Dennis Ritchie; this is a theoretical question)?
[side note: I've got this book at home; I am _very_ far away from understanding everything. However, I liked the first chapter a lot and it seems that I understand most of this chapter...]

I confirm that this issue affects me too on the Aquaris E4.5 Ubuntu Edition.

Also affects Mako, even with a simple script like

#!/bin/bash
if [ -d "$HOME/bin" ] ; then
    echo found
fi

This works in an adb shell, but not in the terminal on the phone. In the phone terminal
. ./test.sh
as mentioned here:-
http://askubuntu.com/questions/613564/how-to-run-a-shell-script-on-ubuntu-touch
executes it ok

Here some short facts:

1st: bash/shell scripts from home-directory give this error:
bash: ./script: /bin/bash: bad interpreter: Permission denied

2nd: exactly same scripts in /usr/bin are working fine

3rd: If you are loged in via ssh, then it doesn't matter, where the scripts are.

4th: One short look in /etc/passwd will show you, that the user "phablet" does not really exist anymore. (In 14.10 you could find user phablet in that file.)

So all in one: I think, that it is possible, that point 4 is the reason, that you can't execute bash-scripts. (In 14.10 there I had no problems with.)

> If you are loged in via ssh, then it doesn't matter, where the scripts are.

Good! So this gives us a workaround:
  ssh localhost

And indeed, after this, shell scripts work :-)

> 4th: One short look in /etc/passwd will show you, that the user "phablet" does not really exist anymore.

... is now in /var/lib/extrausers/passwd

> So all in one: I think, that it is possible, that point 4 is the reason, that you can't execute bash-scripts.

Nope, if you log in using ssh, you are the same user, and there it works. I think, it's rather a matter of apparmor "permissions" on the terminal app, or something like this...

> EDIT: It seems that the contents of the home directory can also be accessed in /userdata/user-data/phablet/ and there I can run the testscript I created using "./testscript". I now aliased "cdh" with "cd /userdata/user-data/phablet" and added it to my .bashrc file. When I want to execute a shell script in my home directory I now only have to enter "cdh" and then I can execute shell scripts as expected.

Great! Actually, you can just put the following at the end of your .bashrc file:
PATH=/userdata/user-data/phablet/bin:$PATH

This just puts bin from under that userdata directory into your PATH, so you can call yours scripts without needind to cd back and forth

Good Idea!

To be honest though, I have my scripts lying around in a few places, but I could put all of them in my PATH so that shouldn't be a problem.
Alternatively I could just add the line "cd /userdata/user-data/phablet" to my .bashrc file to always be in the home directory where I can execute my scripts/programs. Since /userdata/user-data/phablet must be mounted to /home (or something similar, but I'm unable to find that out) those directories contain the same data anyway.

Still, I wonder why I can't execute executable files in one of the directories but not in the other...

What does the script do? Could you attach it so someone else can try to reproduce the bug?

> What does the script do?

*any* script shows the problem, no matter what its contents, as long as it is called from the terminal app, under the directory /home/phablet:

It works correctly from an ssh session.

It works correctly from the terminal app when called as /userdata/user-data/phablet/ (is physically same directory as /home/phablet, but problem shows only for /home/phablet, but not /userdata/user-data/phablet/ )

> Could you attach it so someone else can try to reproduce the bug?

#!/bin/sh

echo "Hello world"

Really, all of this is in the description, just forward it to a developer already :-)

I confirm it does not work.

I tried the "hello world" script in comment #36, made it executable, and got the error:
bash: ./script.sh: /bin/sh: bad interpreter: Permission denied

Then I had a look at the AppArmor output, and I found this:

phablet@ubuntu-phablet:~$ sudo dmesg | grep DEN
[30173.807064] type=1400 audit(1454077173.210:351): apparmor="DENIED" operation="exec" profile="com.ubuntu.terminal_terminal_0.7.140" name="/home/phablet/script.sh" pid=10165 comm="bash" requested_mask="x" denied_mask="x" fsuid=32011 ouid=32011
[30395.224341] type=1400 audit(1454077394.620:352): apparmor="DENIED" operation="exec" profile="com.ubuntu.terminal_terminal_0.7.140" name="/home/phablet/Documents/script.sh" pid=11727 comm="bash" requested_mask="x" denied_mask="x" fsuid=32011 ouid=32011
phablet@ubuntu-phablet:~$

Which confirms what I've already seen when I was working on some of my projects: unconfined apps are not really unconfined.