Show HN: c (github.com)

    And those on Mac should be able to use:
    
    $ brew install c

Wow, uh, didn't it strike you that this might be a bad idea?

Great idea - I think 'c' should be a shell alias though.

Tagging support would be cool.

Terrible, terrible name.

    $ jot -b test -c 3
    test
    test
    test

I would rename it to something else and just alias it to 'c'.

This is really cool! Thanks for sharing.

I'd also like to point out that the Twitter account you link to for contact looks extremely inactive.

Googling topics on "C" has been tough for me for the past 15 years.

Bonus point for me trying to filter out C++.

Comments for your C learning:

    #include <stdbool.h>

is better than

    typedef int bool;
    #define true 1
    #define false 0

Always, always, surround your if and else clauses with brackets. There are plenty of ways leaving them naked will screw you over. This goes for any language.

This is terrifying, and broken:

    char * s = malloc(snprintf(NULL, 0, "%s/%s", cwd, argv[1]) + 1);
    sprintf(s, "%s/%s", cwd, argv[1]);

Passing NULL to snprintf, first of all, should be a huge red flag for you. If it's not, train yourself to recognize it. I realize what you're trying to do, but it relies on non-portable behavior. In particular, from the manual:

    The glibc implementation of the functions snprintf() and vsnprintf() conforms
    to the C99 standard, that is, behaves as described above, since glibc version
    2.1.  Until glibc 2.0.6 they would return -1 when the output was truncated.

So until glibc 2.0.6, your program would be allocating 0 and then sprintfing into it. Always be careful when you read the manual, to read everything. And even then, program defensively, and train yourself to watch for errors like this one. In this case, passing NULL as the destination argument was an immediate no-no.

In this function, you really should be checking errno (for ENOENT). stat(2) can fail for all sorts of reasons, one of them is that the entry is not there.

    bool dirOrFileExists(const char dir[]) {
	struct stat st;
	if (stat(dir, &st) == 0) {
		return true;
	}
	else {
		return false;
	}
    }

Same for this loop, check errno to make sure the function's failing for the reason you think it should.

    while((entry = readdir(mydir)))

Here, you have something a little messy:

    int fileOrDirectory(const char path[]) {
	struct stat s;

	if (stat(path, &s) == 0) {
		if (s.st_mode & S_IFDIR) {
			// Is a directory
			return 0;
		} else if (s.st_mode & S_IFREG) {
			// Is a file
			return 1;
		} else {
			// Something else
			return -1;
		}
	}
	else {
		// Error
		printf("Error occurred\n");
	}
    }

First of all, returning values only you know about is bound for destruction. You should define an enum if you want a function to return specific states. Better yet, just do these checks in the function that would normally call this. It's not so bad usually, and you're probably calling stat(2) more than you should. It's a syscall, and those can be expensive. But more importantly, you have a branch where all you do is print something (to stdout, not stderr as you should), and then just return nothing! If you hit an error state, you need to either propagate that error up and handle it in the caller, or crash immediately. Don't leave your program in a garbage state and keep going. A compiler should have warned you about this (not having a return value in one branch). Turn on -Werror and at least -Wall. And fix your warnings, don't try to suppress them.

You should use fscanf(3) instead of this:

    while (1) {
	ch = fgetc(fp);
	newch[i] = ch;
	if (ch == EOF) {
		newch[i] = '\0';
		break;
	}
	i++;
    }

That's all for now, I gotta go. Good luck!

  #ifdef PATH_MAX
  char cwd[PATH_MAX];
  long len = sizeof cwd;
  #else
  char *cwd;
  long len;
  if((len = pathconf(".", _PC_PATH_MAX)) < 0)
    len = 8192; /* some arbitrary value */
  cwd = malloc(len);
  #endif

    if (getcwd(cwd, sizeof(cwd)) != NULL)
        ;
    else
        perror("getcwd() error");

Is that common? What's the advantages over the below?

    if (... == NULL) {
        perror(...);
    }

It may be more appropriate to store the comments in extended attributes rather than in dotfiles: http://en.wikipedia.org/wiki/Extended_file_attributes

4DOS used to have this. It was especially useful back in the day with the 8.3 DOS filenames, which often weren't very descriptive. It's nice to see this feature return.

4DOS used to have a similar feature. It was especially useful back in the day with the 8.3 DOS filenames, which often weren't very descriptive. It's nice to see this feature return.

Hidden files are handy for some things, but a README.txt file would be apparent to anybody who comes across the directory, and not just someone who knows that the hidden directory is/may be there.

Why did you decide to use autoconf?

Wouldn't it be better to use Extended file attributes ? https://gist.github.com/2695264 (actually my first attempt to a bash script)

As a sub-novice C/++ programmer myself, it's awesome to see a program like this being discussed. The source code is relatively short, it's a simple enough implementation, and all the feedback in the comments here is teaching me things I wouldn't necessarily be exposed to in a book.

I love this post and the exchange of comments going on here. The OP is just starting to learn C, and to help learn it got started on a project that they found useful, which I think is one of the best ways to learn programming.

The community then responded by posting helpful feedback, much of which demonstrates the idiomatic way of doing things, which is often one of the most difficult things to learn when picking up a new programming language. Other helpful advice is posted on build options and debug tools.

This kind of constructive and useful feedback is great to see.