C programming with FreeBSD

6502 said:
1. Install clang
2. Try nano / pico

I prefer to use Visual Studio from Windows as editor and then compile in console (via PuTTY).
Click to expand...
Is VSCode or VSCodium the same thing that you are talking about? I don't need Windows for these.
 
yonnieboy said:
Ports? I'm so new to FreeBSD I haven't figured out how to install it yet. I'm gathering that the term "ports" has nothing to do with a computer's i/o?
Click to expand...
All out-of-base external software that is available on FreeBSD are written in through the Ports framework, when they are being compiled and served to users, they are called packages of official FreeBSD package repositories.

Also, you can quote all messages and post them in a one reply.

FreshPorts is a good website for browsing through ports and to gather info about them.

You should have been the ports tree installed if you had chosen to install ports.txz set in first install of FreeBSD. If not, you can pull them using devel/git.
git clone https://github.com/freebsd/freebsd-ports
 
yonnieboy said:
either requires extensive memory faculties, which I don't have. I'll have to make a cheat sheet.
Click to expand...
Well, if so far you've gotten used to more complicated and feature-loaded editors, like most GUI editors are, then, sure, ed(1) (which is line-oriented, not screen-oriented as other editors) will be a really unusual and new experience for you. I remember, I was thinking exactly the same, when I heard about ed. I didn't believe that anyone can really use it for text editing that involves more than just 'add a short line of text, save and close the file'. But suddenly, I got interested and decided to give it a try. I read the whole manual page (re-read it dozen more times later, of course) and just started practicing it for simple tasks (essentially, start trying to do all the things I have been doing with other editors with ed). BTW, I must say that ed(1) man page is very good, just read through all of it. To my great surprise, it wasn't difficult at all. Granted, a completely different approach to text editing, but not hard. I went from not being able to even add some new text to the file to writing from scratch and editing a ~1000 lines of C program solely with ed.

It doesn't require one to use ed for everything - just stick with what you like more. But if you want to feel all the power of UNIX environment and tools - I strongly encourage you to give ed a try. Not only it's very handy (in fact, now I edit system configuration files only with ed - works perfectly fine), but also makes use of re_format(7) 'basic' regular expressions (BREs) and, whether you want it or not, forces you to master them at some level. A bunch of other UNIX tools use BREs as well: sed(1) (essentially, stream version of ed(1)), grep(1), find(1), ...). I bet you'll find them helpful someday too; it would be easier to use them when you already know the RE syntax.

So, to sum it up: it's not that hard as you think, it just comes with practice :)
 
yonnieboy said:
Ports? I'm so new to FreeBSD I haven't figured out how to install it yet. I'm gathering that the term "ports" has nothing to do with a computer's i/o?
Click to expand...
In FreeBSD term 'port' is used to refer to a piece of third-party software. Be careful to not got confused: this terminology and meaning of 'port' are specific to FreeBSD. For example, NetBSD uses 'port' to refer to a supported architecture.

Essentially, term 'port' here comes from 'porting' - applying changes to the software for it to be able to run on another OS. Today, with contemporary compilers and standards, most of the programs are written the way they can run on a dozen OSes without fiddling with them much. But back in the day, it was much more on the cards. Still today we have cases when particular software is written for a particular OS and it needs 'full' porting so to speak.

It is important that port implies that you fetch the source code of the software and compile it on your machine (and then optionally install). Don't worry, this task can be automated.

In FreeBSD ports are represented as 'ports tree' (or sometimes it's called 'ports collection'). Ports tree is a huge hierarchy of directories and files. Usually it's located in /usr/ports. Simply put, a directory - is a port, and it contains a bunch of (usually, around one dozen, but often even less) simple text files that describe how to build this program. In this small text files there are instructions how to download the source code, unpack it, then, if needed, apply some changes (patches) to the source code (this is the abovementioned 'porting') and then compile the program. In the end, you will get a ready-to-run binary executable file, that you can install on your system.

Building the software from ports may be tricky and requires some confidence with the system. Also it requires decent hardware and with huge programs (like web-browsers) it may literally take days to build them. Another option is 'packages' or 'binary packages'. Remember, when you've compiled the port from sources, you got an executable binary? Now imagine that this 'porting' (downloading, patching, compilation) was done not on your machine, but on some other one that did all the work and spitted out a binary file to you. And now imagine that it did it not only with this single port, but with all the ports available in FreeBSD (as for July 2025, there are about 33000 ports available). So, you don't have to imagine, because this is exactly what's happening: powerful FreeBSD servers build all the ports and serve binary result for users. These 'results' are called 'packages'.

To sum it up: 'install a port' means go into /usr/src, find the directory you need, compile the program and the install it. 'install a package' means go ahead and pick up the binary package for desired program that has already been built and served.

It was a general introduction to ports and packages. I failed to mention some things, for example, that building a port yourself allows you to adjust some settings or options to fit your needs, meanwhile binary packages don't allow such luxury.

Technical details: for manipulating packages, FreeBSD uses package manager pkg(8) (see also pkg(7)). For dealing with ports(7), make(1) commands are issued. There are also some programs that allow to deal with ports more easily, for example, portmaster(8).

If you got interested and want to get more details, you can continue with FreeBSD Handbook dedicated chapter.
 
bare bones...
Code: 
$ cat > ./test.c
#include <stdio.h>
int main(int argc, char* argv[]) {
    printf("hello world!\n");
    return 0;
}
^D
$ cc ./test.c
$ ./a.out
hello world!

and when you are ready, the teco editor awaits you. LMAO
 
yonnieboy said:
oh boy!! That's nice stuff! I just bought a book C Primer and it's companion C++ Primer. And I need my laptop running so I can practice as I read.
Click to expand...
Dude, forget all abount C++. Learn C first. And preferably never bother with C++, a pox on that unholy abomination, spawn of the Sith lord 😫, the path to the dark side! Bury that C++ book at the bottom of the box of books you're never going to read, where it belongs... or preferably leave it lying around at work until it disappears one day and let some other poor sucker waste their cycles on it.
 
Definitely work through the 'programming' section of the freebsd manual; a very nice introduction.

Grab a copy of this one true book too, known universally as "K&R". It's the only book you need, although 'C primer' is fine.
archive.org

C Programming Language, 2nd Edition By Brian W Kernighan, Dennis : Free Download, Borrow, and Streaming : Internet Archive

The C Programming Language
archive.org

Another nice book about C is this not so very well known one by Mike Banahan, although it may be a little out of date now.
publications.gbdirect.co.uk

The C Book - Table of Contents

publications.gbdirect.co.uk

But truly, K&R is all you need. Work through K&R. I think there is a book of worked solutions to the questions that has been published too.

All you need is a text editor. Vi, gnu nano, nedit, any standard text editor will be fine. You could use freebsd's 'ee' easy editor perfectly well to learn with.
 
Don't forget to read, dream and live "Kernighan & Ritchie: The C Programming Language". If you only buy one book on C, this is the one to put under your pillow. It's dense, each word counts, but that's how the C gurus like it.
 
In all seriousness, I've been programming for 35 years and all the free IDEs fall short, IMHO. I have a hate-hate relationship with eclipse because while it provides the functions I want in an IDE, it has always been buggy as hell. Worse yet, most vendors use it as their base dev environment for specialized stuff like embedded programming, but only their recommended version, and using their plugins. Tried VSCode and wanted to give it a fair shake but I won't stand for apps that seriptitiously leak data the the net. The only way I could disable the "feature" was to run it from a uid that was blocked from having network access, and then a whole bunch of annoying timeouts started occuring. ... and don't get me started on design process templates. Few things are more annoying than being expected to follow a pre-defined setup path for a project, and usually not being able to make changes to the core template without going thru the whole process again from scratch....and oh, while you think you deleted the old project, the IDE metadata thinks it still exists so you have to choose a different name when you recreate the project.

In the end, I end up freeform coding using geany or vi, and writing my own scripts and makefiles for the build process, running them in a separate xterm. It sucks because I'd give my right pinky for a working symbol indexer, but they all seem broken by design.
 
kent_dorfman766 said:
[…]
In the end, I end up freeform coding using geany or vi, and writing my own scripts and makefiles for the build process, running them in a separate xterm. It sucks because I'd give my right pinky for a working symbol indexer, but they all seem broken by design.
Click to expand...
Isn't editors/neovim supposed to support LSP (language server protocol) out of the box? In theory, you could use an indexer like clangd from devel/llvm19 and integrate it into neovim. But I have not yet given it a try myself, though.
 
OP I highly recommend Advent of Code come winter time. It may be summer for others. They should restructure the event for northern and southern hemispheres. More info: Wiki - Event page: Main page
 
yonnieboy said:
What are the first basic steps to do this with FreeBSD?
I open an editor such as VI and write the code? Then how do I invoke the compiler? I'm imagining I need a folder setup to save to in advance?

And this would be a similar process for other programming as well?
Click to expand...

What do you want to learn programming for? If it’s the OS then unfortunately you are almost obliged to use C.

If it is for userland applications then I recommend avoiding C at all costs. The only thing going for it is fast build times. C is a basket case for safety and security. Learn Rust or modern C++ instead.
 
cracauer@ said:
Just to clarify. my Rust comment was a forum inside joke. Don't do that. And don't do C++ either until you have a reasonable grasp on C.
Click to expand...

No. Just avoid C if you can.

Unless you actually want to learn how to write code with memory lifetime issues, type confusion bugs, bounds errors, uninitialised memory and leaks.
 
Paul Floyd said:
The only thing going for it is fast build times.
Click to expand...
I would suggest that interop with the OS (i.e POSIX APIs) is even more important than the build time as the benefits of C for userland development.

This is where I also would also lean towards C++ (modern being C++11 safety related, i.e member variable initialization, smart pointers rather than the "ease of use" gimmicks) as the ideal compromise between bindingless interop and safety.
 
You need to know "C" in order to correctly call *BSD/Linux/Unix/etc system calls. Whether you like it or not you will likely also have to pass malloc()ed memory into and from those same system calls as well so you need to learn "C" memory management techniques as well.

Learning "C" is extremely helpful if you are going to be a full time *BSD/Linux/Unix programmer.
 
CShell said:
You need to know "C" in order to correctly call *BSD/Linux/Unix/etc system calls. Whether you like it or not you will likely also have to pass malloc()ed memory into and from those same system calls as well so you need to learn "C" memory management techniques as well.
Click to expand...

Funny. In the past few days I've written a few testcases in C++ that directly call syscalls and throw exceptions if they don't return the right value and set errno correctly.

CShell said:
Learning "C" is extremely helpful if you are going to be a full time *BSD/Linux/Unix programmer.
Click to expand...

That depends on a lot of things. Until recently the USA and the EU were heading to be much stricter with regards to accountability for commercial software. The US under Trump seems to be backpedalling to become regulation lite so maybe CISA won't carry through with what is was working on. In the EU the CRA has been enacted.

en.wikipedia.org

Cyber Resilience Act - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Paul Floyd said:
In the EU the CRA has been enacted.

https://www.cisa.gov/case-memory-safe-roadmaps
https://en.wikipedia.org/wiki/Cyber_Resilience_Act
Click to expand...

In the UK at least, the only way this is actionable is to move back to Ada (mainly the SPARK subset). But weirdly we seem to be moving more and more away from that and onto C++.

We will not be seeing i.e Ferrocene hit the streets in our professional lifespan. For one it will take a long time to get it certified for DO-178C. And DO-330 even pushes towards having multiple compiler vendors, which is a pain point for the new kids on the block Rust, Go, Zig, etc.

This memory safe roadmap is obviously not designed by developers on the ground. Lets be honest, it was clearly lobbied by the Rust marketing department.
 
tembun said:
To my great surprise, it wasn't difficult at all. Granted, a completely different approach to text editing, but not hard.
Click to expand...
There are variants of ed that are also interesting:

1) sam (that have also a GUI), but it is in some sense something completely different.

2) ex, that is also the command mode of vi.

But as tembun says, is a completely different approach: if you are using (n)vi, you will not like to give ex commands.
 
CShell said:
You need to know "C" in order to correctly call *BSD/Linux/Unix/etc system calls.
Click to expand...
Most other programming languages have bindings for system calls and C library calls (or equivalent language-native facilities for libraries). Look at Java, Perl, Python. Understanding C is not a bad idea, but writing in C is not required for that.
 
kent_dorfman766 said:
bare bones...
Code: 
$ cat > ./test.c
#include <stdio.h>
int main(int argc, char* argv[]) {
    printf("hello world!\n");
    return 0;
}
^D
$ cc ./test.c ./a.out
$ ./a.out
hello world!
Click to expand...
I frankly think that this is the simplest way to get started with C on FreeBSD. After all, the basic premise of UNIX is Keep It Simple, Stupid.

Once OP tastes success with that, OP can expand and chase other ideas, they all build off that simple tutorial.

But as for text editor flamewar, I strongly recommend implementing editors/nano in brainfuck. 🤪
 
You must log in or register to reply here.
Back
Top