[Courses] C Programming For Absolute Beginners, Lesson 1: Setting Up, First Program

Lesley Piper lesley.a.piper at gmail.com
Mon Feb 13 09:47:21 UTC 2012


Hi!
I have successfully compiled and ran the Hello World example. Also, the
hexdump worked, but when I type the strings command, all I see is "Hello,
and welcome to the Beginning C Course,"  I do not see this:
/lib/ld-linux.so.2
__gmon_start__
libc.so.6
_IO_stdin_used
puts
__libc_start_main
GLIBC_2.0
PTRh0
[^_]

I'm assuming I did something wrong, but I'm not sure what =(

- Piper

On Sun, Feb 5, 2012 at 12:56 AM, Carla Schroder <carla at bratgrrl.com> wrote:

> ## C Programming For Absolute Beginners, Lesson 1: Setting Up, First
> Program
> ##
>
> Prequisites: Please know your Linux basics, how to use a text editor, the
> bash
> shell, and how to find and install software.
>
> You need gcc, the GNU Compiler Collection. Your favorite Linux distribution
> should pull in any dependencies like cpp, binutils, and glibc, the GNU
> shared
> C library. libc6 is the same as glibc version 2, and you should see libc6
> installed on your system as libc.so.6 or libc.so. Yes, we love naming
> confusion on Linux don't we.
>
> Coders need good typing skills. There are many free typing tutors, and if
> you
> spend ten minutes per day practicing you'll see your typing skills improve
> rapidly.
>
> You'll need some patience and persistence. Anyone can learn to do anything,
> including become a good coder. Everyone taking this course comes from
> different
> backgrounds and levels of experience, so don't compare yourself to your
> fellow
> students, or think you're too slow or too stupid or have the wrong kind of
> brain. Learning anything isn't about raw blazing brilliant talent, but
> working
> at it. Everyone who is a good coder has invested a lot of time and effort.
>
> Lessons run weekly, every Sunday, and I estimate about 16 weeks.
>
> All lessons and messages are archived at
> http://mailman.linuxchix.org/mailman/listinfo/courses
>
> ## Lesson 1: Setting Up, First Program ##
>
> I recommend typing rather than copy-and-pasting the examples, because it
> trains your eyes to see details, and when you're writing code details are
> everything. If you miss a single character such as a semi-colon or curly
> brace
> your code will not work correctly.
>
> C is a compiled language. Writing the code is just the first step; then it
> must
> be compiled using a program called a compiler, like gcc.
>
> code > compile > executable binary
>
> This creates an executable binary, which is our actual program. (This is a
> very simplified explanation, which is all we need for the moment.)
>
> The classic beginning program is always a "Hello World!" program, or
> something
> similar. It's a fast and easy way to learn the basic steps of write code,
> compile code, and then run the resulting executable. Type this example
> source
> code into a text editor and name it whatever you want, except test, because
> Linux already has a command called test. My example is called welcome.c. It
> must have the .c extension so that gcc knows this is a C source code file:
>
> #include <stdio.h>
> main()
> {
>  printf( "Hello, and welcome to the Beginning C Course!\n" );
>  getchar();
> }
>
> Now compile it:
>
> $ gcc -o welcome welcome.c
>
> The -o option means "give the output file this name." If you don't name
> your
> output file gcc will call it a.out.
>
> And now you can run your new compiled program:
>
> $ ./welcome
> Hello, and welcome to the Beginning C Course!
>
> You must prepend your new command with ./ when you are running it from
> inside
> its directory. If you go up one level, then you just need the normal
> filepath,
> for example if I put welcome in my cfiles directory:
>
> $ cfiles/welcome
>
> Or you can put it in a directory that is your path. Run echo $PATH to see
> all
> of your paths:
>
> $ echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
>
> This means that any command placed in any of these directories can be run
> without typing out the full filepath, because the bash shell knows to look
> in
> these directories when you enter a command. When you're writing your own
> code
> it can be helpful to create a directory in your home directory to store
> your
> executables, to avoid permissions hassles. Then put your new directory in
> your
> path by adding a line to your ~/.profile, like this:
>
> PATH=$PATH:$HOME/cfiles
>
> Then logout and log back in. Copy welcome to your new directory, and the
> which
> command will see it:
>
> $ which welcome
> /home/carla/cfiles/welcome
>
> And you can run it like any other command, with just the command name:
>
> $ welcome
>
> You can read your nice plain-text source code file, but a binary
> executable is
> a different kettle of clams. You can read it with the hexdump command,
> which
> spits out giant blobs of hexadecimal:
>
> $ hexdump welcome
> 0000000 457f 464c 0101 0001 0000 0000 0000 0000
> 0000010 0002 0003 0001 0000 8300 0804 0034 0000
> [...]
>
> A more useful command for binary files is strings, which extracts all of
> the
> text strings:
>
> $ strings  welcome
> /lib/ld-linux.so.2
> __gmon_start__
> libc.so.6
> _IO_stdin_used
> puts
> __libc_start_main
> GLIBC_2.0
> PTRh0
> [^_]
> Hello, and welcome to the Beginning C Course!
>
> ## Explaining the Source Code File ##
>
> Now let's dissect our new source code file. #include <stdio.h> is a
> preprocessor directive that tells gcc to include the code from the header
> file
> stdio.h in our little program. A preprocessor directive always starts with
> the
> pound sign, and you can have more than one. stdio.h is plain-text source
> code,
> so you can read it. stdio.h is a standard C library header that is used in
> pretty much all C programs because it handles input and output-- input from
> files and the keyboard, and output to files or the screen. Code libraries
> are
> wonderful things because we can re-use them and not start over completely
> from
> scratch every time we write a new program.
>
> The next part is the function main, which is the first function executed
> in a C
> program. All C programs must start with the main() function. A function is
> a
> block of code dedicated to performing a particular task. A function is
> made up
> of statements, which are instructions, which end in semi-colons. Our
> example
> main() function includes two statements:
>
> main()
>  {
>    printf( "Hello, and welcome to the Beginning C Course!\n" );
>    getchar();
>  }
>
> printf is a built-in C function that formats and prints the text in the
> parentheses to the screen. The parentheses enclose the arguments, or
> values,
> that are passed to the function. A function must always be followed by a
> set
> of parentheses, even when there are no arguments. Any text string in an
> argument must be enclosed in double quotes. \n is a newline, and a
> semi-colon
> terminates the statement.
>
> getchar(); is a hack. I don't recall if this is a Windows behavior, or if
> it
> happens in some Linux environments; at any rate on some systems when our
> little example program finishes running the whole terminal closes, so all
> you
> see is a quick flash and it's gone. getchar(); makes the program wait for
> a key
> press before it closes. If you don't need getchar(); you can delete it, or
> comment it out. There are two ways to comment C code. This way comments a
> single line:
>
> // getchar();
>
> This way comments a multi-line block:
>
> /*
>   getchar();
> */
>
> Or all on one line:
>
> /* getchar(); */
>
>
> Well that's all for today. But don't be sad because there is homework!
> Please
> feel free to share your own discoveries, thoughts, and questions on the
> list.
>
> 1. Enter more text for the printf function to work on, and try different
> formatting options from man printf.
>
> 2. Look up the spec for stdio.h, and see what the various macros and
> functions
> in the spec look like in your own stdio.h file.
>
> 3. Make errors on purpose in your source code file and see what the
> compiler
> does.
>
> Thank you all, and I'm looking forward to some good discussion!
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Carla Schroder, ace Linux guru and howto author
> 541-932-4817 PT
> carla at tuxcomputing.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Courses mailing list
> Courses at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/courses
>



-- 

Certainly, travel is more than the seeing of sights; it is a change that
goes on, deep and permanent, in the ideas of living.  ~ Miriam Beard


More information about the Courses mailing list