So be a little bit clearer for you folks that are wondering what’s going on. ~/ti for william on this system is the mount point for an NFS share. Both machines have user william, but it is possible that the UID for each is different. I’ve run into this problem before, and it creates all sorts of strange behavior. So, I’ll write a simple hello world executable locally, in tmpfs . . .
Adding symlinks and NFS with a different UID will certainly skew the results! Umask does have an effect, it determines what permissions a file gets created with, regardless of how you create it. Mike
william@beaglebone:~/ramfs$ cat test.c
#include<stdio.h>
int main()
{
printf(“hello world !\n”);
return 0;
}
william@beaglebone:~/ramfs$ gcc test.c -o test
william@beaglebone:~/ramfs$ la -al test
-bash: la: command not found
william@beaglebone:~/ramfs$ ls -al test
-rwxr-xr-x 1 william william 5047 Mar 25 18:31 test
william@beaglebone:~/ramfs$ umask 022
william@beaglebone:~/ramfs$ test
william@beaglebone:~/ramfs$ umask 0137
william@beaglebone:~/ramfs$ test
william@beaglebone:~/ramfs$ ./test
hello world !
william@beaglebone:~/ramfs$ chmod u+x test
william@beaglebone:~/ramfs$ test
william@beaglebone:~/ramfs$ umask 022
william@beaglebone:~/ramfs$ test
william@beaglebone:~/ramfs$ sudo test
sudo: test: command not found
william@beaglebone:~/ramfs$ umask 0137
william@beaglebone:~/ramfs$ sudo test
sudo: test: command not found
william@beaglebone:~/ramfs$ export PATH=$PATH:/home/william/ramfs/
william@beaglebone:~/ramfs$ test
william@beaglebone:~/ramfs$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/william/ramfs/
At this point I decided that the executable “test” is a bad choice for some reason unknown to me.
william@beaglebone:~/ramfs$ mv test.c hello.c
william@beaglebone:~/ramfs$ rm test
william@beaglebone:~/ramfs$ ls -al
total 8
drwxrwxrwt 2 root root 60 Mar 25 18:36 .
drwxr-xr-x 4 william william 4096 Jan 3 16:16 …
-rw-r–r-- 1 william william 74 Mar 25 18:26 hello.c
william@beaglebone:~/ramfs$ gcc hello.c -o hello
william@beaglebone:~/ramfs$ hello
-bash: /home/william/ramfs/hello: Permission denied
william@beaglebone:~/ramfs$ chmod +x hello
william@beaglebone:~/ramfs$ hello
-bash: /home/william/ramfs/hello: Permission denied
william@beaglebone:~/ramfs$ sudo hello
sudo: hello: command not found
william@beaglebone:~/ramfs$ ./hello
-bash: ./hello: Permission denied
william@beaglebone:~/ramfs$ chmod u+x hello
william@beaglebone:~/ramfs$ sudo hello
sudo: hello: command not found
oops forgot about umask . .
william@beaglebone:~/ramfs$ umask 022
william@beaglebone:~/ramfs$ sudo hello
sudo: hello: command not found
d’oh, of course this wont work . . . the executable is not in roots path.
william@beaglebone:~/ramfs$ hello
hello world !
william@beaglebone:~/ramfs$ ./hello
hello world !
william@beaglebone:~/ramfs$
So yes, really weird the executable “test” is not working correctly on this system, and yes, I ran which test, and in fact . . .
ooops forgot to add this.
william@beaglebone:~/ramfs$ which test
william@beaglebone:~/ramfs$ sudo su
root@beaglebone:/home/william/ramfs# which test
root@beaglebone:/home/william/ramfs# exit
exit
william@beaglebone:~/ti$ gcc test.c -o test
william@beaglebone:~/ti$ test
'test' is a bash builtin
william@beaglebone:~/ti$ ./test
32.540001william@beaglebone:~/ti$ sudo ln -s /home/william/ti/test /usr/bin/test
Careful. '/usr/bin/test' is often a real program for
shells that don't have builtin 'test'. Which you just
overwrote.
william@beaglebone:~/ti$ test
william@beaglebone:~/ti$ cd ..
william@beaglebone:~$ test
william@beaglebone:~$ sudo test
32.540001So, it's a permissions issue. . .
Nope. shell builtin aliasing.
This thread has so much bad advice in it.
Regards,
Peter Hurley
Careful. ‘/usr/bin/test’ is often a real program for
shells that don’t have builtin ‘test’. Which you just
overwrote.
I had no idea . . . good thing this is a test image - heh. Thanks Peter 
root@ticktock:/dev# type test test is a shell builtin root@ticktock:/dev# type -a test test is a shell builtin test is /usr/bin/test root@ticktock:/dev# Mike
Your not getting the usage of umask at all. It doesn’t change permissions on an existing file… I’d suggest man umask… Mike
lol . . . way off the point by now.
But since we’re way off point I will make my disappointment known. First, Linux is purportedly know as the developers OS by developers, yes ? So with that in mind it’s probably a good assumption that many people are going to be developing software on it. So . . .anyone care to take a stab at what the most common executable name will be for test applications ?
Could I have checked for “test” as an existing executable ? Yes, certainly, but would I in any right state of mind even think that I should check ? No, probably not . . . So yes, I could probably be a better user and look before I leap, but why in hell would an default anything named test exist on any Linux system ? Guess we’ll either have to ask the maintainer(s) of bash and ask them wtf they were thinking, or just move on . . .
Hi Mike,
The way I think about this is umask turns off permission, which means that the execute permission is provided by gcc.
For example:
MBPR:~ john$ umask
0022
MBPR:~ john $ touch test
MBPR:~ john $ ls -la test
-rw-r–r-- 1 john staff 0 Mar 25 22:15 test
MBPR:~ john $ gcc -Wall -o hello hello.c
MBPR:~ john $ ls -la hello
-rwxr-xr-x 1 john staff 8432 Mar 25 22:17 hello
As you can see, 022 is turning off “group" write and “other" write permissions. So normally, touch would provide 0666, but when umask is 022, permission is anded with the inverse of umask, which provides 0644. So gcc would create a file with 0777 if umask was 000.
Regards,
John
I think it should be pretty clear, and if this is not abundantly clear to new users. DO NOT USE umask Period. good bye, the end.
One should leave the default settings and instead work with the system as intended. Instead of creating a serious potential security hole.
Strange. I’m not sure there is a way to not use umask. With umask=022, the purpose is to set the default permission for newly created files or directories, so only the owner has write permissions. How is that a security flaw? I guess you can always make umask=000, but then you are enabling everyone write permissions as the default and that is a security flaw.
Regards,
John
You do not have to. I’ve been trying to tell you all that umask is already set by default. Screwing around with umask passed that is a recipe for disaster. Unless you know exactly what you’re doing, and then you do not need to listen to me.
Again, it was a terrible idea to even bring up umask, as such now every newb is going to be screwing around with, and the person who brought it up should be “held liable” for damages. Then we’ll see how often people here start giving advice willy nilly . . .
william@beaglebone:~$ cat /etc/login.defs |more
. . .
UMASK is the default umask value for pam_umask and is used by
useradd and newusers to set the mode of the new home directories.
022 is the “historical” value in Debian for UMASK
027, or even 077, could be considered better for privacy
There is no One True Answer here : each sysadmin must make up his/her
mind.
Yes (original answerer here), I was wondering about all the
corrections.
The *default* output file is a.o but if you specify with -o then you
get the name you say, no .o added.
I did mean to add the 'chmod +x <filename>' but got distracted, it
seems that gcc is cleverer than I expected! 
Er, unfortunately you have it completely wrong!
You need to say './<filename>' when the executable in question is not
on your PATH. Doing a 'chmod +x' won't help at all.
Say you are in a directory /home/chris/dev and you have created a
program (compiled C, bash script, whatever) in that directory called
myprog then, in order to be able to run it directly (as opposed to
feeding it as a parameter into an interpreter), it will have to have
the executable bit set:-
chris$ ls -l myprog
-rw-rw-r-- 1 chris chris 15 Mar 26 14:23 myprog
chris$ chmod +x myprog
chris$ ls -l myprog
-rwxrwxr-x 1 chris chris 15 Mar 26 14:23 myprog
chris$
Then there are two basic ways to run it, firstly you can specify the
path to the executable:-
chris$ /home/chris/dev/myprog
or, if /home/chris/dev/myprog is the current directory:-
chris$ ./myprog
Secondly you can set the PATH environment variable to include the
directory where the executable is:-
chris$ PATH=$PATH:/home/chris/dev/myprog
chris$ myprog
Not to belabor the point but I am in about the same situation as Brainiac.
Is there a cookbook guide to compiling, linking, and running C programs on beaglebone? It seems that most BB folks are comfortable with linux toolchain but many people come to this board with little linux knowledge, eg. from arduino or even a bare metal world.
Your suggestions on bootstrapping into a bit of activity with the board are welcome!
Richard
To Richard Cook:
My personal recommendation is Derek Molloy’s:
Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux
by Derek Molloy for John Wiley & Sons, 2014 – ISBN 9781118935125
Book WebSite: includes errata, discussion
http://exploringbeaglebone.com/
Source Code:
https://github.com/derekmolloy/exploringBB/
It has a lot of basic information about setting up a cross-compile system using Eclipse,
and how to work with the low level I/O and basic Linux commands
He is on faculty at Dublin City University.
The only problem, is that the book is now two years old, and the BeagleBone systems
are moving fast, so you may need to adjust some things for newer operating systems releases,
and newer tool versions.
— Graham
@Richard Cook
First thing one needs to understand. Just because the hardware is a beaglebone, does not mean it needs anything special in regards to toolchain’s. As long as the tools have an ABI compatible binary, we’re fine. The ABI it’s self we do not really need to worry about. It’s already in place. Which means any book on the GNU compiler collection( gcc ) would be suitable for such a purpose. This one is a bit out of date, but it’s free !
https://tfetimes.com/wp-content/uploads/2015/09/An_Introduction_to_GCC-Brian_Gough.pdf
So not to belittle Derek Molloy, but he does not strike me as an expert in compilers, linkers, and what not. In fact, I probably know more about gcc, and I’m no expert. His book Exploring Beaglebone is a fine book, but does not cover toolchains in detail.
On Fri, 25 Mar 2016 18:17:50 -0700, William Hermans
<yyrkoon@gmail.com> declaimed the following:
umask has no effect on the current situation. None, period, zip.
And what does your PATH environment variable look like? Both user
account and root account...
As I recall from ages ago (On a Mandrake installation, to give an
example of age)... the root account PATH included "current directory" via
"."; user accounts did NOT -- as a security feature to avoid having stuff
user's may have downloaded taking precedence over a proper system provided
program. User's had to either knowingly change their PATH to include "." or
to, again knowingly, specify current directory when invoking a program
using the "./" prefix.
Appears my BBB doesn't have current directory included in either
account
debian@beaglebone:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
root@beaglebone:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@beaglebone:~#
william@beaglebone:~/ti$ gcc test.c -o test
william@beaglebone:~/ti$ test
That's because it's the wrong test. type 'which test' and it'll probably
say /usr/bin/test. If you don't specify the path, it's using the PATH
variable which is not supposed to contain current dir early on, precisely
to avoid this type of surprise. Note that on Windows, they automatically
prepend . to the PATH, which is why Windows is famous for confusing 'DLL
hell' where nobody knows where your executables/libraries are coming from.
william@beaglebone:~/ti$ ./test
32.540001
right, you specified the path, so it's using your executable
william@beaglebone:~/ti$ sudo ln -s /home/william/ti/test /usr/bin/test
you don't need sudo here: you're creating a local symbolic link (I assume
that you are in /home/william/ti directory)
You overwrote the 'test' executable with a link to /usr/bin/test
william@beaglebone:~/ti$ test
still using /usr/bin/test
william@beaglebone:~/ti$ cd ..
william@beaglebone:~$ test
william@beaglebone:~$ sudo test
32.540001
I don't know what happens here---maybe your root has a different path that
contains '.' early on (it shouldn't!)