C compiler

[Brainiac]

hi eeveryone,

does the BeageleBone Black have a C compiler ?????

i want to controle a step by step motor using BBB with C language , and i'm wondering if the BBB has an integrated C compiler 

[Dieter Wirz]

gcc

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Wadi Ben Rhouma]

thx ,sorry i have another question, i'm not failiar with LINUX , so can u help me with this , how can i write a C code on the terminal and excute it on my BBB ?? 

 

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Q6Ed3hfRQag/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Wadi Ben Rhouma

Vice Président ENET'COM Junior Entreprise

Tél : +216 53 56 61 70

E-mail : wadi.ben...@gamil.com

Facebook : https://www.facebook.com/wadi.benrhouma

Skype : benrhoumawadi

--Dream as if you'll live forever; Live as if you'll die today.--

[Wadi Ben Rhouma]

thx ,sorry i have another question, i'm not familiar with LINUX , so can u help me with this , how can i write a C code on the terminal and excute it on my BBB ?? what command i have to use???

2016-03-25 11:55 GMT+01:00 Dieter Wirz <didi...@gmail.com>:

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Q6Ed3hfRQag/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[c...@isbd.net]

Wadi Ben Rhouma <wadi.ben...@gmail.com> wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 66 lines --]

>
> thx ,sorry i have another question, i'm not failiar with LINUX , so can u
> help me with this , how can i write a C code on the terminal and excute it
> on my BBB ??
>

Create your code in a file called, say, myprogram.c.

Then:-

gcc -o myprogram myprogram.c

This will create a compiled program called myprogram which you can
execute by typing its name at the command prompt. For C++ you can do
the same using g++ instead of gcc.

For more complex programs and libraries it gets more involved.

--
Chris Green
·

[Graham]

And after you create the file for the first time, you will need to change its permissions

so that it is executable.

use an incantation like:

sudo chmod 755 myprogram.c

You will really need to become familiar with the basics of Linux, if you are 

working on a Linux platform like the BeagleBone Black.

--- Graham

==

[Seppo Nikkilä]

myprogram.o

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Developing next generation wireless audio

[Graham Haddock]

Yes.

sudo chmod 755 myprogram

or

sudo chmod 755 myprogram.o

--- Graham

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Q6Ed3hfRQag/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Dieter Wirz]

On Fri, Mar 25, 2016 at 3:57 PM, Graham Haddock <gra...@flexradio.com> wrote:
> Yes.
> sudo chmod 755 myprogram
> or
> sudo chmod 755 myprogram.o
>

Graham, please do not tell fairy tails on this list!

$ echo '#include <stdio.h>' > hello.c
$ echo 'int main (void) { printf ("Hello, world!\n"); return 0; }' >> hello.c
$ cat hello.c
#include <stdio.h>
int main (void) { printf ("Hello, world!\n"); return 0; }
$ gcc -Wall -o hello hello.c
$ ./hello
Hello, world!
$ ls -l
total 12
-rwxrwxr-x 1 dw dw 7332 Mar 25 16:32 hello
-rw-rw-r-- 1 dw dw 80 Mar 25 16:31 hello.c
$

No chmod needed, no myprogram.o there, why the sudo????

[William Hermans]

No chmod needed *IF* you precede the command with a dot slash "./". So when you run a regular Linux command do you have to type this dot slash ? No because chmod +x is run on the executable at some point . . .

So be nice to fellow group users who actually know what they're talking about, and have been on this list a lot longer than you.

[Mike]

On 03/25/2016 02:03 PM, William Hermans wrote:

No chmod needed *IF* you precede the command with a dot slash "./". So when you run a regular Linux command do you have to type this dot slash ? No because chmod +x is run on the executable at some point . . .

So be nice to fellow group users who actually know what they're talking about, and have been on this list a lot longer than you.

Maybe we need to learn what ./ does...  It has absolutely nothing to do with a files permissions or whether it's executable or not.  It's use is regarding the lack of the current directory "." in one's PATH variable.  Umask is (largely) what controls what permissions a file is created with.

mike@pride-n-joy:~/test.d$ ls -al
total 12
drwxr-xr-x  2 mike mike 4096 Mar 25 17:07 .
drwxr-xr-x 37 mike mike 4096 Mar 25 16:46 ..
-rw-r--r--  1 mike mike   78 Mar 25 16:47 hello.c
mike@pride-n-joy:~/test.d$ umask
0022
mike@pride-n-joy:~/test.d$ gcc -Wall -o hello hello.c
mike@pride-n-joy:~/test.d$ ls -l
total 12
-rwxr-xr-x 1 mike mike 6696 Mar 25 17:08 hello
-rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
mike@pride-n-joy:~/test.d$ hello
bash: hello: command not found
mike@pride-n-joy:~/test.d$ ./hello
Hello, world!
mike@pride-n-joy:~/test.d$ umask 0137
mike@pride-n-joy:~/test.d$ gcc -Wall -o hello hello.c
mike@pride-n-joy:~/test.d$ ls -l
total 12
-rw-r----- 1 mike mike 6696 Mar 25 17:09 hello
-rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
mike@pride-n-joy:~/test.d$ hello
bash: hello: command not found
mike@pride-n-joy:~/test.d$ ./hello
bash: ./hello: Permission denied
mike@pride-n-joy:~/test.d$ ls -l
total 12
-rw-r----- 1 mike mike 6696 Mar 25 17:09 hello
-rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
mike@pride-n-joy:~/test.d$ chmod 0750 hello
mike@pride-n-joy:~/test.d$ ls -l
total 12
-rwxr-x--- 1 mike mike 6696 Mar 25 17:09 hello
-rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
mike@pride-n-joy:~/test.d$ ./hello
Hello, world!
mike@pride-n-joy:~/test.d$ umask 022
mike@pride-n-joy:~/test.d$ umask
0022
mike@pride-n-joy:~/test.d$

Mike

[William Hermans]

No, Mike is absolutely correct. dot's meaning in this context is current directory, and slash is just a path modifier / separator. Putting the file in ones $PATH would solve the "problem" of having to use dot slash I've know  this forever, I do not know why I was thinking that chmod +x would solve that "issue", because it wont.

I do recall at some point perhaps not too long ago that changing file permissions to executable was required. But now days this does not seem to be the case . . . I've always in the last several years use ./executable until I put the executable into my local path . . .

[William Hermans]

Im guessing that perhaps gcc's -o option now days enables the executable bit on the output file ? I haven't looked into that however.

[Mike]

On 03/25/2016 08:11 PM, William Hermans wrote:

Im guessing that perhaps gcc's -o option now days enables the executable bit on the output file ? I haven't looked into that however.

Nothing at all to do with gcc, reread what I already posted...

[William Hermans]

Nothing at all to do with gcc, reread what I already posted...

Your system, and mine behave nothing alike. For instance if I attempt to run an executable without using dot slash prefixed. The executable will simple fail silently.

[William Hermans]

william@beaglebone:~/ti$ gcc test.c -o test
william@beaglebone:~/ti$ test
william@beaglebone:~/ti$ ./test
32.540001

william@beaglebone:~/ti$ sudo ln -s /home/william/ti/test /usr/bin/test
william@beaglebone:~/ti$ test
william@beaglebone:~/ti$ cd ..
william@beaglebone:~$ test
william@beaglebone:~$ sudo test
32.540001

So, it's a permissions issue. . .

[Robert Nelson]

On Mar 25, 2016 8:03 PM, "William Hermans" <yyr...@gmail.com> wrote:
>
> william@beaglebone:~/ti$ gcc test.c -o test
> william@beaglebone:~/ti$ test
> william@beaglebone:~/ti$ ./test
> 32.540001
>
> william@beaglebone:~/ti$ sudo ln -s /home/william/ti/test /usr/bin/test
> william@beaglebone:~/ti$ test
> william@beaglebone:~/ti$ cd ..
> william@beaglebone:~$ test
> william@beaglebone:~$ sudo test
> 32.540001
>
> So, it's a permissions issue. . .

chmod +x test

Regards,

[William Hermans]

chmod +x test

Regards,

Yeah, thats what I thought too, but it doesn't work. I suspect in my case the symbolic link is getting in the way. But thats not the only issues thats going on. Looking into it

--

[Mike]

On 03/25/2016 09:03 PM, William Hermans wrote:

william@beaglebone:~/ti$ gcc test.c -o test
william@beaglebone:~/ti$ test
william@beaglebone:~/ti$ ./test
32.540001

william@beaglebone:~/ti$ sudo ln -s /home/william/ti/test /usr/bin/test
william@beaglebone:~/ti$ test
william@beaglebone:~/ti$ cd ..
william@beaglebone:~$ test
william@beaglebone:~$ sudo test
32.540001

So, it's a permissions issue. . .

Exactly, yet you haven't show any of the file permissions in your above foray.

Again I'll say it umask is largely what controls how permissions are set when files are created.  This is basic *nix 101...

[William Hermans]

umask has no effect on the current situation. None, period, zip.

[William Hermans]

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 . . .

[Mike]

On 03/25/2016 09:22 PM, William Hermans wrote:

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.

[William Hermans]

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 . . .

[William Hermans]

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

[Peter Hurley]

On 03/25/2016 06:03 PM, William Hermans wrote:
> william@beaglebone:~/ti$ gcc test.c -o test
> william@beaglebone:~/ti$ test

'test' is a bash builtin

> william@beaglebone:~/ti$ ./test
> 32.540001
>
> william@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.540001
>
> So, it's a permissions issue. . .

Nope. shell builtin aliasing.

This thread has so much bad advice in it.

Regards,
Peter Hurley

[William Hermans]

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 :)

[Mike]

On 03/25/2016 09:51 PM, William Hermans wrote:

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

[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

[William Hermans]

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 . . .

--

[John Syne]

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

[William Hermans]

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.

[John Syne]

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

[William Hermans]

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.
#
# Prefix these values with "0" to get octal, "0x" to get hexadecimal.
#
ERASECHAR       0177
KILLCHAR        025
UMASK           022
. . .

[Richard Cook]

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 

On Friday, March 25, 2016 at 5:40:29 AM UTC-5, Brainiac wrote:

hi eeveryone,

does the BeageleBone Black have a C compiler ?????

i want to controle a step by step motor using BBB with C language , and i'm wondering if the BBB has an integrated C compiler 

[c...@isbd.net]

Dieter Wirz <didi...@gmail.com> wrote:
> On Fri, Mar 25, 2016 at 3:57 PM, Graham Haddock <gra...@flexradio.com>
> wrote:
> > Yes.
> > sudo chmod 755 myprogram
> > or
> > sudo chmod 755 myprogram.o
> >
> Graham, please do not tell fairy tails on this list!
>
> $ echo '#include <stdio.h>' > hello.c
> $ echo 'int main (void) { printf ("Hello, world!\n"); return 0; }' >> hello.c
> $ cat hello.c
> #include <stdio.h>
> int main (void) { printf ("Hello, world!\n"); return 0; }
> $ gcc -Wall -o hello hello.c
> $ ./hello
> Hello, world!
> $ ls -l
> total 12
> -rwxrwxr-x 1 dw dw 7332 Mar 25 16:32 hello
> -rw-rw-r-- 1 dw dw 80 Mar 25 16:31 hello.c
> $
>
> No chmod needed, no myprogram.o there, why the sudo????
>

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! :-)

--
Chris Green
·

[c...@isbd.net]

William Hermans <yyr...@gmail.com> wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 52 lines --]

>
> No chmod needed *IF* you precede the command with a dot slash "./". So when
> you run a regular Linux command do you have to type this dot slash ? No
> because chmod +x is run on the executable at some point . . .
>
> So be nice to fellow group users who actually know what they're talking
> about, and have been on this list a lot longer than you.
>

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


--
Chris Green
·

[Graham Haddock]

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

==

[William Hermans]

@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.

[Dennis Lee Bieber]

On Fri, 25 Mar 2016 18:17:50 -0700, William Hermans
<yyr...@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:~#
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Przemek Klosowski]

On Fri, Mar 25, 2016 at 9:03 PM, William Hermans <yyr...@gmail.com> wrote:

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!)

 

So, it's a permissions issue. . .

No, I really don't think so