[cheerios]

Ok, JUST starting out with C as a programming language, and in class, they're making us use vi editor in Unix. I decided I'd do my homework in Project Builder, and regain the use of my arrow keys and backspace, because I'm finding it VERY hard to break the habit of hitting up and down arrows... i KNOW my code is correct, because i can compile and run it in terminal, with cc and gcc... but when I run it in project builder, the printf commands don't happen till AFTER all the scanf commands, even though i have prints before scans. Very technical description, I know, but I'm tryin' here. So, I need to feed it all the input it wants, before it will output ANYTHING, even the prompt for the input.

Is there any way to fix this? or does PB's support for C just suck? I like the interface and all, but if it can't even build a project correctly, it's back to vi and the terminal for me :-/

[fitter]

PB's console I/O is certainly a little buggy, and will likely never be as reliable for console applications as Terminal. I've seen several cases where PB echoes the input before dispensing the output. Since you like PB's interface, you could edit and compile code there, but then test it in Terminal. A little clumsy, sure, but it solves your problem. I do recommend you continue learning to use vi. Once you've got it down, it becomes the fastest way to move through and edit text files of all available methods. Mac OS X's version is actually very forgiving about the use of arrow keys: you shouldn't have to use the HJKL system built into vi unless you want to, on OS X, though of course it's a good idea to become accustomed to it. The best way to learn the use of vi is through a tutorial called VILEARN. Search for it on the web, it's freely available.

By the way, why are they teaching you to use scanf? It's inherently insecure. Better to use fgets or getc for standard input.

[cheerios]

truly, i had no clue there was an alternative... we're in like the 2nd week of classes, and the class is just so us engineering majors can hack little programs for specialized uses, or so my understanding is. We're only spending about half hte semester on it, although I'll probably learn more, since my boyfriend is a comp sci major. why is is insecure, out of curiosity?

[alien]

I think there is a buffer owerflow problem with scanf. (To read data without array bounds checking.)
http://www.suse.com/en/support/howto.../secprog1.html

[ramenite]

speaking as a TA for a C and Unix class.....

You really should use vi. vi can be set up very nicely to code with. If you need an .exrc file to set it up better for coding, I'll be happy to e-mail it to you. The point of teaching vi it not because it's just an editor, it's THE editor. PB, emacs, pico, etc. aren't default installs on alot of unix systems. vi or one of it's variations like vim will be on every unix system you will come in contact with. Hence, why it's taught in the majority of unix and c classes you'll take, including mine. I don't have a prefrence either of any editor in particular myself. I use them all interchangably. One of the few unix people you'll see with that opinion ;-)

[petej]

Originally posted by fitter:
<STRONG>By the way, why are they teaching you to use scanf? It's inherently insecure. Better to use fgets or getc for standard input.</STRONG>

scanf is not inherently insecure, but it's easy to use it in insecure ways. Make sure that if you use scanf (or sprintf), you specify limits in the format converters for strings -- for example, if you are trying to read a string into a buffer six characters long, you should use a format specifier of %.5s (remember that scanf will always put a NUL character in the buffer to terminate the string).

gets, on the other hand, is inherently insecure. One should always use fgets instead of gets, because there's no way to specify bounds in gets, and fgets does the same thing as gets, but allows bounds specification.

The article alien referenced has a good explanation of this, including good do/don't code.

[absmiths]

I hate to be the single naysayer here, but I would avoid vi like the plague (and all other CL editors). A basic understanding of vi is nice (navigation + some basic editing commands) but I would hardly call it indispensable. Windows is also likely to be on every other computer in the world but we are using OS X, right?

Anyway, soapbox aside, I use BBEdit (TextEdit, BBEdit Lite and PB do just as well). I work predominantly from the terminal, but when I want to open a file I use open:

localhost&gt;open WorkFile.c

And that will cause my associated app (BBedit) to open the file. It is also nice that it opens asynchronously so I don't have a whole stack of terminal windows with vi running in them.

Bottom line - it is nice (I wouldn't say essential) to be familiar with tools like vi (or notepad - probably the most-encountered least-common denominator), but in your home environment rely on the strengths of the tools at hand. vi is no match for BBEdit or even notepad for that matter.

I forgot to mention that I rely on make for the time being since that allows me to edit the files in BBEdit and invoke make periodically to determine progress. I run from the command line as well.

[ 01-29-2002: Message edited by: absmiths ]

[clarkgoble]

Speaking of moving to Project Builder from other IDE's.

I mainly do standard c-library stuff so my code usually runs just in terminal. Now I've been doing most of my coding in Visual C++ on my Windows machine. But I've found that running my code on both my Mac and my Win2K machine finds a lot of bugs and helps keep me cross-platform. (All those little quirks of Microsoft)

However like a few in this thread mentioned, moving over to PB as a quick and dirty IDE didn't really work that well. I still use it to edit my source, as I like the editor. But I can't quite get it to reliably build my projects.

Is there a good makefile builder for the command line that is standard on OSX? If not, is there a good one to download? That's about the only real issue as I hate having to remember what to modify in my Makefile every time I transfer code.

[absmiths]

Originally posted by clarkgoble:
<STRONG>Speaking of moving to Project Builder from other IDE's.

...[SNIPPED]...

Is there a good makefile builder for the command line that is standard on OSX? If not, is there a good one to download? That's about the only real issue as I hate having to remember what to modify in my Makefile every time I transfer code.</STRONG>

You could just use 'make'. This is the version of make that comes installed by default (with developer tools):

&gt;GNU Make version 3.79, by Richard Stallman and Roland McGrath.
&gt;Built for powerpc-apple-darwin1.4

Rather than constantly altering your makefile, why don't you just define different targets, WIN32 or MACOSX? You will have to make changes between cc and the Microsoft C-compiler. Makefiles are a lot easier to keep in sync than IDE project files.

[clarkgoble]

Actually that's what I do. What I mean is that most IDEs go through your *.h and *.cpp looking for relationships to create the equivalent of a Makefile. So if I add some headers or something it is a bit of a pain to update everything. The alternative (which I must confess I do when lazy) is simply rebuild everything. But that's not too elegant.

So, for instance, under the old Codewarrior or under Visual Studio you add *.cpp and *.h files to your project and it intelligently keeps track of what needs updated.

Don't get me wrong. Makefiles are much, much more handy. And heaven knows there are times when I've used those features. (i.e. all those YACC programs I've written) But there is also something to be said for an IDE's ability to quickly and easily add files.

I'm sure there is a program out there that generates Makefiles from your code. I'm just caught back in the early 90's in terms of knowing Unix utilities. (LOL)

[clarkgoble]

Someone suggested GNU's automake. Apparently it gets installed with FINK, so I guess I'll take an other stab at getting FINK to work. (I tried once before but something went wrong and it didn't want to install anything)

Oh - I should add (keeping on thread) that the fact that the terminal oriented programs can't easily be debugged by Project Builder is why I still do all my primary development on Windows. Were Apple to improve the debugging (stepping through) regular programs I'd probably convert. It is just too much hassle to get things working right though.

[ 01-29-2002: Message edited by: clarkgoble ]

[Mactoid]

Originally posted by clarkgoble:
<STRONG>Oh - I should add (keeping on thread) that the fact that the terminal oriented programs can't easily be debugged by Project Builder is why I still do all my primary development on Windows. Were Apple to improve the debugging (stepping through) regular programs I'd probably convert. It is just too much hassle to get things working right though.</STRONG>

Could you please elaborate on that? I have done a good number of console apps, and haven't had any problems debugging (aside from my platform agnostic mental deficiencies ). Not everything is available from the GUI, but that's why the gdb console is there.

Probably the biggest problem I see with the GUI is lack of a global variable display.

[BlackGriffen]

To get back on the thread topic, the project builder console does have a bug, however, there is a kludge that will get you around it. Every time you want it to output successfully, just use fflush(stdout);. I personally prefer to use the actual terminal when possible, but I still haven't learned the ropes with the real gdb; the gui for examining variables is just too convenient.

As for editors, I avoid vi like the plague (*shudders*). From the sounds of it, vi can be used, but emacs is just so much more intuitive! It automatically handles syntax formatting (how far you need to tab inward), automatically backs up your work (both a previous version of the file that ends in ~, and an auto-saved file with a title #like_this.c# that it saves every couple of minutes while you work, and erases if emacs quits successfully). It does have a lot of commands, but it's damn powerful. Consider that it's the only Unix editor with an alt.religion news group (no joke: alt.religion.emacs isn't very active, but it does exist). You can even get syntax highlighting if you upgrade to a newer version than the one that came with OSX.

If you want to compile in the command line, and you're program only has one .c file (that has #include calls to standard libraries), I know that you can compile the program with "cc filename.c" (less quotes, of course). I don't know the exact limits of just using cc to compile, but I know that it will work with these limits. You're program will be in the directory you ran cc from and it will be named a.out.

Have fun!
BlackGriffen

[ 01-30-2002: Message edited by: BlackGriffen ]

[jamieorc]

but emacs is just so much more intuitive!

Hah!

It took me a year of on and off use to make emacs feel even remotely "intuitive." However, I use it a lot across platforms now. (The jde for java is great.) I use various editors for different tasks because I like the way they do different things or handle different code.

Jamie

[amonitzer]

Originally posted by clarkgoble:
<STRONG>I should add that the fact that the terminal oriented programs can't easily be debugged by Project Builder is why I still do all my primary development on Windows.</STRONG>

That's why I always use gdb in a terminal for debugging. Works fine at source-level, including GUI-apps. gdb is much more powerful than Project Builder's frontend, and it's very reliable (PB crashed on me multiple times when I tried to debug).

[McKenna]

I found the answer from a helpful soul...

Before all of your scanf commands in your code (assuming you haven't ditched PB by now), include this line:

fflush(stdout);

And the world is a wonderful place, once again...

--Tom (amateur C coder...)

Originally posted by cheerios:
<STRONG>Ok, JUST starting out with C as a programming language, and in class, they're making us use vi editor in Unix. I decided I'd do my homework in Project Builder, and regain the use of my arrow keys and backspace, because I'm finding it VERY hard to break the habit of hitting up and down arrows... i KNOW my code is correct, because i can compile and run it in terminal, with cc and gcc... but when I run it in project builder, the printf commands don't happen till AFTER all the scanf commands, even though i have prints before scans. Very technical description, I know, but I'm tryin' here. So, I need to feed it all the input it wants, before it will output ANYTHING, even the prompt for the input.

Is there any way to fix this? or does PB's support for C just suck? I like the interface and all, but if it can't even build a project correctly, it's back to vi and the terminal for me :-/</STRONG>

[mefogus]

Although the fflush(stdout) method may work, I wouldn't recommend it because I think that you want to keep the number of kludges in your code to a minimum. As others have mentioned, PB has not inherant advantages when writing CLI code, and there are other tools that work just as well (and even better). The virtues/flaws of VI have already been mentioned (and seem to be stirring up the associated religious war), so I won't go into them. IMO, BBEdit and Emacs are better options, but the choice is up to you... give them a try.

-m

[theolein]

Just starting as I am on my ObjC/Cocoa journey and frequently having to do server work for other people on their servers I switch between PB for ObjC and vim for everything else. vim is close enough to vi that most of the standard commands work in both and you can customise it to death. I have colour syntax highlighting set up in my vim and it does the syntax highlighting properly for Java, Perl, C, ObjC, PHP, HTML and just about everything else. I have come to work with vim in one terminal, compile in another, and run in yet another and finally have a list of files in a forth. Works very well. And there is a saying in the Unix world : if nothing else works vi will work.

Cheerios: You could possibly just get used to typing in ":help" every time you get stuck. I found the vi/vim documentation second to none. I found that once you get used to the basics in vi such u - undo, i - insert, o - insert line, x -delete character and dd - delete line and the help files you can work very speedily.