You are not logged in.
Pages: 1
Hi. I haven't posted much on this forum. Never on this board. I thought I could give asking for anyones thoughts here. So as the title says I'm beginning to make myself learn C.
I started to make myself learn how to use bash for scripting, for one because it's super useful on linux system, it comes in handy all the time now that I understand what's going on.
But more importantly when i first started considering learning to write code, and I started reading up on a bit. I realized, that this is an entirely different way of thinking about things that I am not used to.
So I thought learning a higher level scripting language, that I already partially understand from using it in the terminal would be a great way to start learning how to solve problems with a program.
Now I've finally moved onto learning C. I've gone through a bit on all the basics. Going over all the keywords of the language, learning about the differnt loops, variables, data structures. pointers. While doing that I used some interactive coarses.
But they definitely at least partially hand you the answer so I didn't feel confident I would be able to fully know how to take advantage of them in real applications. So I decided to start a project to write a shell. Which I'm still working on. I've gotten the basics down.
As in it will run the loop, fork and exec a program, or a builtin, wrote a couple builtins for it, like cd, and pwd. But I want to take it as far as I can. I've gotten to the point where I'm probably going to have to write a parser. I stopped there, and decided to try rewriting the coreutils to give myself some smaller projects to learn a bit more, I've written cat, and I'll move onto some of the others, then come back to the parser for the differnt parts of the shell language I will need to do. And I've kind of realized it would be really helpful if I had anyone that actually knew how to program already that I could ask questions. I don't want to have someone else solve the problems for me, because I'm only doing this to learn. But I feel like at a certain point struggling through it all on my own is making things harder than it has to be. Certainly harder than it would be if I was in school for this or something. I'm obviously reading through the documentation, the man pages, I have the devdocs for C also. I got the info pages for libc as well. Also I've saved some pages to look through things.
I think the main thing I want is to be able to ask people what direction they might go at solving a problem, and maybe explain their reasoning. Or something I might not know at all about why they would choose it at my current knowledge level. I guess the main question if there is one. Is where is a good place I can find people to ask this kind of stuff. I know if I have a specific problem I'm trying to solve I could probably ask here. Or maybe I could make a stack exchange account, then ask there. But I feel like there is probably some benifit to being able to talk through some of this with people, or at least someone that already knows a bit. I feel like with sh/bash scripting there is a lot that is self explanitory once you learn the basics, and what things like [ ] || && & | : ; mean or the basics ideas of the if else, while, for, and case statements. Even if there are some peculiarities, and some more advanced things you will definitely learn along the way. With C, even though in a lot of ways it's a simple language, everything else about it isn't simple at all. Or at least it doesn't seem simple. There is so much to think about. Stack allocated vs heap, handling memory when it's dynamically allocated (learning when to free, and making sure you stay within the allocated space), knowing when using one data structure might make sense over another. There are so many ways to do everything, and there is so much to learn about. Even after learning the most basic parts of what the language provides.
Last edited by blankyblank (2025-12-12 05:52:31)
Offline
Read K&R (2nd edition), if you haven't already. Also, a good place to ask questions is the #c channel on Libera.chat. Be warned they tend to focus mostly on the standards for the language, which say nothing about stacks or heaps. Man pages are useful but sometimes contain OS-specific extensions to C; if you want authoritative information, read the standards.
"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.
Offline
By far the best way to learn programming is to do programming. Don't worry about all the nuances yet, you'll apply them when you need them.
Instead, start writing working code. Write a silly app that takes 10 numbers from the console and then output the numbers and their average. Then write another that instead takes the 10 numbers from a text file.
See if you like the whole process of typing in code in an editor, figuring out which API calls to make, creating your makefile, compiling, fixing, and linking it. If you truly like doing all that, then you'll succeed in any language for any project.
Offline
Read K&R (2nd edition), if you haven't already. Also, a good place to ask questions is the #c channel on Libera.chat. Be warned they tend to focus mostly on the standards for the language, which say nothing about stacks or heaps. Man pages are useful but sometimes contain OS-specific extensions to C; if you want authoritative information, read the standards.
I haven't I'll check it out K&R. thanks for the recommendations.
By far the best way to learn programming is to do programming. Don't worry about all the nuances yet, you'll apply them when you need them.
Instead, start writing working code. Write a silly app that takes 10 numbers from the console and then output the numbers and their average. Then write another that instead takes the 10 numbers from a text file.
See if you like the whole process of typing in code in an editor, figuring out which API calls to make, creating your makefile, compiling, fixing, and linking it. If you truly like doing all that, then you'll succeed in any language for any project.
Yeah, that's why I've made writing a shell. Then I went to do my own versions of the coretutils. I know there isn't goingt to be any other way to learn, other than doing it. Obviously you have to know the technical details of the language, and that's half of it. But the other big part is understanding how to implement them.
Like I mentioned in the OP I got through the begining of writing the shell, to the point where it works in the most basic sense, has a couple builtins, but then got to the point where I'm going to have to write some kind of more advanced parser. And kind of realized I might need to practice a bit more with some smaller projects, then come back to this one as a more advanced project to learn on. So i thought doing the coretuils seemed like a nice way to learn as I go. One important thing to me is I feel like I need to work on something that keeps my interest while I do it. Which is why I picked a shell, and the coreutils also. I fee like they're probably good projects that cover a wide range of things to learn, but also they're useful, and i personally find them interesting.
This is all just for me to learn, but maybe at some point making some kind of project myself could be nice. Like some kind of cli, or something. I don't really have much interest in getting a software job or anything, but I definitely wouldn't mind contributing to FOSS projects at some point in the distant future.
edit: just a little side note. While I was working on the shell. I downloaded the source code for a few different shells, 9base which has rc, dash, bash, tcsh, and zsh. I would have thought going into it bash bash or zsh might have the craziest source, and bash definitely does have some stuff going on that is above my head at this point, a lot of magic going on with macros and all that. But tcsh was the thing that really seemed the most complex of them all. I feel like of the source code I looked at in zsh it wasn't so bad. It also helped that everything is pretty extensively commented, or at least a lot of it is. also dash seemed reasonable. They all are doing things I wouldn't quite know how to work with at this point. rc from 9base, which is a suckless recreation of the plan 9 utils is pretty much exactly what I expected to see, because I've seen a lot of suckless code before, or programs based on the suckless philosophy like dwl.
Last edited by blankyblank (2025-12-13 04:54:11)
Offline
Try focus on technical things when you post around here. I believe that's the primary focus of this board and Arch Linux in general. Prose input/posts might not get you the best results.
Offline
Try focus on technical things when you post around here. I believe that's the primary focus of this board and Arch Linux in general. Prose input/posts might not get you the best results.
I asked here, because it said it was for "programming issues and discussion" in the description of the board. Also in the contributing and discussion subforum (or whatever you would describe the categorization). If it meant something else by discussion, then I guess I misunderstood.
Offline
Try focus on technical things when you post around here. I believe that's the primary focus of this board and Arch Linux in general. Prose input/posts might not get you the best results.
This is a very strange remark. Nothing about blankyblank's posts seem unusual for this forum, to me. And how else is one supposed to describe technical things other than in prose? And how is learning C not technical?
"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.
Offline
Moderator Note
Arch Linux Forums are a technical support forum, but there's room for discussions also.
Sofar I see nothing wrong in this thread.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
ReDress wrote:Try focus on technical things when you post around here. I believe that's the primary focus of this board and Arch Linux in general. Prose input/posts might not get you the best results.
This is a very strange remark. Nothing about blankyblank's posts seem unusual for this forum, to me. And how else is one supposed to describe technical things other than in prose? And how is learning C not technical?
I'm not trying to be rude here but honestly, that looks like someone's life story to me :-(
Offline
I feel like I need to work on something that keeps my interest while I do it.
My advice is to change this attitude/philosophy/approach and instead find the inspiration/drive/desire in *solving* whatever problem you're facing, even if it seems well "above your head", as you put it yourself. You describe yourself as someone that loses interest when the going gets tough. If writing a parser is tough (and it is!), embrace that. Steal how other projects have taken that on, there's plenty of "build your own parser" libraries around, research those. Fall down - fail miserably - get back up - succeed.
You'll soon realize that most code out there is far, far from perfect. It typically just barely does what it's supposed to do, poorly and wrought with issues of future compatibility, vulnerabilities, poor maintainability, etc. As if it was made by people just like yourself, not some magical flawless hacker demon....
Offline
Someone once asserted that 'C' is really just a universal assembler. I think Ritchie even agreed.
My suggestion would be to really strive to understand pointers, data structures and pointer arithmetic. It is truly what makes C. Lack of understanding (and respect) of pointers is also what causes most of the problems with C code.
There is a book called "The C Puzzle Book". It is a collection of puzzles that should not be considered to be good examples of how to write code -- but rather are challenges to read and figure out in your head how a program will behave. It provides good insight to many C concepts. If you find the book, look up the puzzle 'Pointer Stew'
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Yeah.
I would actually like to predispose to myself to the fact that my primary motive to unix... is Steve Jobs
RIP, as of 2011. That was my fouth year in high school :-)
.Alongside comex... for he's true to the word
Offline
Sorry I spent the last two or three days, trying to get an openbsd set up working on one of my laptops, and having never used it before I kind of had to learn how they do things. I've ran freebsd in the past, but there is only so much that transfers over. Overall I actually like it. It super simple, in a way that actually feels really nice. It's basically ran off shell scripts, and a pretty minimal set of programs. I think it's what I was hoping freebsd was going to be when I used that.
But I couldn't get it to play video at all on my laptop. And I still haven't I have no clue what's actually wrong. Something is going wrong with their intel driver for my haswell igpu or something. Anyway I decided to not waste another night on that. I'll probably troubleshoot it more in the future. I mainly got that set up, because I wanted to run something with a different libc. I'll probably just reformat my void install, and replace it with void musl, to have that to test on. long term. But I might actually keep openbsd around to use for a few things. Even with it's drawbacks, I really do like it so far.
Someone once asserted that 'C' is really just a universal assembler. I think Ritchie even agreed.
My suggestion would be to really strive to understand pointers, data structures and pointer arithmetic. It is truly what makes C. Lack of understanding (and respect) of pointers is also what causes most of the problems with C code.There is a book called "The C Puzzle Book". It is a collection of puzzles that should not be considered to be good examples of how to write code -- but rather are challenges to read and figure out in your head how a program will behave. It provides good insight to many C concepts. If you find the book, look up the puzzle 'Pointer Stew'
Yeah. I've noticed they definitely do play a very important role. After all strings in C are basically a pointer to the beginning of an array of chars. So you can't have strings without pointers. And there is definitely a lot I have to learn about them still. Like understanding function pointers better, and when they will be usefull. Really there is a lot I have to learn about them still. I definitely just know the most basic stuff.
blankyblank wrote:I feel like I need to work on something that keeps my interest while I do it.
My advice is to change this attitude/philosophy/approach and instead find the inspiration/drive/desire in *solving* whatever problem you're facing, even if it seems well "above your head", as you put it yourself. You describe yourself as someone that loses interest when the going gets tough. If writing a parser is tough (and it is!), embrace that. Steal how other projects have taken that on, there's plenty of "build your own parser" libraries around, research those. Fall down - fail miserably - get back up - succeed.
You'll soon realize that most code out there is far, far from perfect. It typically just barely does what it's supposed to do, poorly and wrought with issues of future compatibility, vulnerabilities, poor maintainability, etc. As if it was made by people just like yourself, not some magical flawless hacker demon....
I think that's probably good advice, about being interested in solving the problem.
Although I wouldn't say I'm giving up on the problem, or loosing interest. I just realized at this point it might make sense to take on these smaller projects, that still are challenging/learning experiences for me at this point. I still plan to come back to it, and work on that, I definitely haven't lost interest in it. I just think realistically it will probably be a good idea to go through a few more of these coreutils (maybe write all of them, or at least the ones in 9base), to get a bit more comfortable with solving problems in C, and more familiar in general. I've been learning quite a lot since I've started working on all of these little projects. I never really put much thought into what functions, or system calls were actually going on underneath the programs I use everyday in my terminal. It's been really informative reading up on everything as I go through implementing each thing. In the past I would stumble onto the section 2 or 3 man pages, and I would have no idea what they were talking about.
Oh. just an aside. looking into metadata stuff now. It's the first time I've had to think about bitmasks really since I've started. It's actually one of the things I've kind of dreaded having to deal with, when I learned they were a thing. As I went through lessons/tutorials. Because I have no idea how binary works on a higher level (or lower level maybe?) other than I know 0 is off, 1 is on. And a bit can be in either state. But working with bitmasks, and binary stuff is definitely one of the more intimidating things to me about C. I could just be overthinking it at this point. I'm sure it will be usefull to trully understand it, but maybe I don't need to know about everything that's happening there. Anyway, because i'm writing mkdir right now, I have to deal with setting the file permissions on the new directory, and from what I'm seeing the way to set the permissions is using setting the bits with the binary operators. I think I'm starting to kind of get it a little, seeing how they are used in this case. But I'm not super confident in my knowledg on it.
Last edited by blankyblank (2025-12-17 10:09:37)
Offline
twelveeighty wrote:blankyblank wrote:I feel like I need to work on something that keeps my interest while I do it.
My advice is to change this attitude/philosophy/approach and instead find the inspiration/drive/desire in *solving* whatever problem you're facing, even if it seems well "above your head", as you put it yourself. You describe yourself as someone that loses interest when the going gets tough. If writing a parser is tough (and it is!), embrace that. Steal how other projects have taken that on, there's plenty of "build your own parser" libraries around, research those. Fall down - fail miserably - get back up - succeed.
You'll soon realize that most code out there is far, far from perfect. It typically just barely does what it's supposed to do, poorly and wrought with issues of future compatibility, vulnerabilities, poor maintainability, etc. As if it was made by people just like yourself, not some magical flawless hacker demon....
I think that's probably good advice, about being interested in solving the problem.
Also, it's horrible advice to recommend a cold blooded approach :-(
The time you spend you researching and working thus far with the "discarded" projects adds up cummulatively
A lot of times it is usually much more technical than you would actually earn/gain from focusing on solving the problem
Offline
Also, it's horrible advice to recommend a cold blooded approach :-(
The time you spend you researching and working thus far with the "discarded" projects adds up cummulatively
A lot of times it is usually much more technical than you would actually earn/gain from focusing on solving the problem
Sorry do you mind clarifying? I just want to make sure I get what you mean. With the way you worded it, I feel like I could interpret what you said 2 different ways.
Offline
C is a very weak language. It is like working with a pen and paper, while someone else is deploying a 10000L bulldozer.
C only becomes powerful when solving system development problems. You know, (but I know you don't know), those sneaky corners that the bulldozer can't get around.
Maybe it sounds like buzzwords but I have my journey with C. Even though my first coding language was was java script.
With Javascript I could pop an alert easily. Ridiculous easily, but two years of learning C wouldn't get me the same, honestly. So I switched to C++ to try and speed things up and that worked a little faster.
A little later I realised I was using C/C++ to solve wrong the kinds of problems...
Last edited by ReDress (2025-12-18 06:19:15)
Offline
C is a very weak language.
Hardly.
Powerful, yes. Dangerous in the wrong hands, yes. Expressive, yes. High level, not so much.
Part of the advantage of C++ is the standard library. The problem of c++ is the standard library.
If you want to run on bare metal, it is C, Assembly Language or Rust. OTOH, Arduino is C++ under the hood.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
ReDress wrote:C is a very weak language.
Hardly.
As a general purpose programming language? Then it's not actually weak but is *very* weak.
If you want to run on bare metal, it is C, Assembly Language or Rust. OTOH, Arduino is C++ under the hood.
Rust has been reported to be slightly slower than C. In a lot of bare metal "places", optimisations are done to the tune of nanoseconds and I doubt Rust will be taking over.
Last edited by ReDress (2025-12-19 04:45:18)
Offline
OP wasn't asking about what the "best" programming language is (whatever "best" means). 99.99% of problems can be solved with every programming language, if you try hard enough. Language comparisons boil down to personal preferences masked with technical jargon (just look up any C/C++ vs Rust discussions).
Languages aren't objectively "weak" - back in the early 2000s I've seen environmental safety systems that guarded hundreds of lives every day written in Visual Basic. Even back then most people would argue that is a "weak" language to the point of liability. The reality was that it just did its job. But I've also seen my share of pure garbage written in VB.
Offline
I am merely guiding the OP on how to learn and get the best out of C :-). There is no "best" language but some of these languages are actually what you would call a niche language. They are only effective and reasonable to use in a particular niche.
Unless I am terribly mistaken, BTW, VB has always been very well backed up by Microsoft infrastructure but what does C get? WinApi?
Edit: but, anyways, maybe I am getting ahead of my own self. @blankyblank - why do you wish to learn C?
Last edited by ReDress (2025-12-23 05:35:33)
Offline
comming from PHP and Java - two high-level object-oriented languages - when I got my hands on the K&R (4th ed. for me) I not just missed objects (although Java's distinct copy-by-value helped me to understand pointers) but also how little is part of the language itself and how much of what I was used to is OS dependent
as an example: while both php and java come with a full network stack and support for common protocols in C just getting a socket heavily depends on whether you're on linux or on windows
another one comming from java: one has to clean up yourself
in java i just throw away all references and the inner workings clean up for me - in C i have to get back every resource back to the system myself - and hace to make sure to not try to reuse it - extremely error prone and cause of so many security issues
ariting C isn't hard - doing it properly is the hard to master thing about it
Offline
comming from PHP and Java - two high-level object-oriented languages - when I got my hands on the K&R (4th ed. for me) I not just missed objects (although Java's distinct copy-by-value helped me to understand pointers) but also how little is part of the language itself and how much of what I was used to is OS dependent
I honestly don't consider PHP to be a high level language. PHP bears insane resemblance to C, particularly(maybe to C++ too) which includes low level artifacts like memory leaks.
Offline
C might have been developed as “universal assembler,” 50 years ago. If we follow this perspective, it also remained an assembler for a platform from 50 years ago. Using a similar tongue-in-cheek simplification, C programs run on an PDP-11 emulator, augmented and molded to fit possibly many scenarios. Completely out of sync with actual hardware after 1990s. Nowadays Java is much closer to hardware than C.
With the original C (that’s early 70s, pre-K&R) we may still say it was described in terms of the underlying computer architecture, since C89 it is not. For the past 36 years C is described in terms abstract and detached from hardware no less than Python is.
The reason I say this is to stop OP from falling into the trap that will hurt them badly later. A trap that victims later explain to themselves through attributing blame to compiler developers, or by inventing stories of “undefined behavior being put into C for $reason.” While it’s really that they are hallucinating about what their code means, and are facing the harsh reality of compilers not sharing the hallucination.
Blankyblank, if your mind even starts to model your program after memory addresses, RAM cells, registers etc., just stop and take a deep breath. Will save you a ton of pain and disappointment. It’s good to understand how the compiler and the libraries work behind the scenes, and some system interfaces may even require you to understand that, breaking away from C’s abstraction. But this is not how C is defined and this is not how your code will be interpreted by the compiler.
Paperclips in avatars? | Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
C might have been developed as “universal assembler,” 50 years ago. If we follow this perspective, it also remained an assembler for a platform from 50 years ago. Using a similar tongue-in-cheek simplification, C programs run on an PDP-11 emulator, augmented and molded to fit possibly many scenarios. Completely out of sync with actual hardware after 1990s. Nowadays Java is much closer to hardware than C.
With the original C (that’s early 70s, pre-K&R) we may still say it was described in terms of the underlying computer architecture, since C89 it is not. For the past 36 years C is described in terms abstract and detached from hardware no less than Python is.
The reason I say this is to stop OP from falling into the trap that will hurt them badly later. A trap that victims later explain to themselves through attributing blame to compiler developers, or by inventing stories of “undefined behavior being put into C for $reason.” While it’s really that they are hallucinating about what their code means, and are facing the harsh reality of compilers not sharing the hallucination.
Blankyblank, if your mind even starts to model your program after memory addresses, RAM cells, registers etc., just stop and take a deep breath. Will save you a ton of pain and disappointment. It’s good to understand how the compiler and the libraries work behind the scenes, and some system interfaces may even require you to understand that, breaking away from C’s abstraction. But this is not how C is defined and this is not how your code will be interpreted by the compiler.
A hardware engineer posting on message board?
Is that what's up?
Last edited by ReDress (2025-12-23 14:18:33)
Offline
Pages: 1