OMG WOW im definitely going to print that post. Tons on info and all in one place
YAY! I currently find this all fun and getting stuck on something is cool since Google is my best friend lol I used Geany before its cool. Right now i use Netbeans for gcc/g++ stuff. Its the same IDE for MPLAB X so i chose it since im familiar with it
Im searching Slackware now so i can see whats its about more. Oh man just want to say thanks so much!
Ok - well, if you're familiar with those tools, then cool; you might want to take a look at Eclipse, too (it may or may not be overkill for what you want to do, though). Like I said, there are tons of IDEs out there. Glad you're having fun; it is pretty exciting!
The funny part of linux i found so far is, when you download a new package to install, after extracting(using tar or gui) you have to ensure its set to run as application then to run it i have to ./appname
Something I want to let you know (or, you'll learn the lesson eventually!):
Try to avoid tarball/zipped packages, unless the developer (or whomever) has left you no choice (or you -need- the upgraded features); generally, a tarball/zipped package is designed (if it doesn't just "install" wherever you dumped it) to put its contents (when you "make install") into the "proper" directories - but then again, if the package is old, or designed for another system, it might put its stuff into a "non-standard" directory for the distro you are using. There is this concept out there of a "Linux Standards Base" - which defines directory structures and a whole host of other things, but some distros follow it, others follow their own, etc. It isn't all the "same" like Windows or such, because there isn't one single "form" of "Linux".
Now - this generally doesn't cause too much havoc - but at the same time, it can! You just have to be aware of it, and why/what is happening. Now, you might have run into packages that are ".rpm" or ".deb" packages (there are other styles as well - but these two are the most common today). These are "proper" packages - for Redhat (rpm) and Debian (deb); they are meant to be run thru a "package manager" software (rpm stands for "Redhat Package Manager"); Redhat as you probably are aware is another common Linux distro.
Anyhow, when a package is in these formats, the installer installs it as designed, and at the same time checks for dependencies (are all the libraries in place, proper versions, etc), and won't let you install it until you satisfy those dependencies (well, you can always force an install, but it will likely be broken). As it installs the files, it builds a database of where and what was installed (including any additional files to satisfy dependencies, and whether other files installed use those files as well). This is so when or if you uninstall it (again, thru the package manager software!) - it knows what to remove, and more importantly, what -not- to remove (in the case of libraries that might have been initially installed with package A, but a later package B used them, so if you uninstall package A, it won't uninstall the libraries, until package B is uninstalled). These package managers aren't perfect, but they are much better than manual tarball/zipped file installs.
This is because with a tarball/zipped package - you don't know where/what got installed, or what the dependencies are, when or if you decide to remove something, or upgrade something (unless you look at the makefile or whatever other system was used, build up lists, compare, etc - for -all- of the tarball/zipped packages you installed!). This ultimately can lead you to a mess (and depending on what you are doing, it could be a big mess). Now, for a development/learning system, it might just be something you'll have to live and learn with (you'll most likely run into similar issues on an embedded system anyway - where you'll be the developer and maintainer of the structure). But keep it in mind, and maybe look into how to use and work with the package manager systems (and packaging tools - there are tools out there to convert tarballs and such into proper packages). You'll also want to understand the Linux Standards Base and all the other stuff as well. Lots of stuff to learn and know - but that's the price of entry, I guess!
Normally - this isn't an issue today for regular users - you just pick and choose your packages from the package manager, and install them. It only becomes an issue if you need an upgraded version of the software, and the developer doesn't provide a proper package, instead opting for a tarball/zip file (I am not certain, though - but I seem to recall seeing something somewhere about package manager software being able to handle these files better today - I tend to stay away from them usually, unless they only dump to the local area - but like I said, there are conversion tools, too).
what is the "./" for? I know i have to use it otherwise i get a command not found.
Well - first off, theres are paths that are searched by the system when you enter a command at the command line - to find the command. If the command isn't found in these paths, then you get the error you see. By default, the current path you are in isn't searched (this is a good thing, btw - though you can change it!). In both DOS and Linux - there is the environment variable called PATH that controls this. At the command line, if you type in "env", you'll see a list of environment variables for your current session (many of these are set up by default, others are set up by the login for the user, and some are set up by various config files for the user that can be setup in the user's home directory). Notice the one called "PATH" - it says something like "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" (your's may be different); these are the paths searched for by the system for your command/file. Notice that "." isn't among them (or it shouldn't be).
"." is the "current path" - if you "cd ." you won't go anywhere. Now, if you did an "ls -als" in the current directory, you'll see at the top a couple of entries "." (current directory) and ".." (previous directory); to go "back" a directory in the hierarchy, you just say "cd .." (for two levels, "cd ../..", etc).
By typing "./command" - you are saying "execute this command in the current directory". Now - like I said, you can add "." to your path structure if you want; you really shouldn't, though, and just get used to using the "./" convention. There are good reasons why you don't want "." to be a part of your execution path (but if you must, add it to the very end of the PATH statement - I'll leave it to you to figure out how to change it).
Ill definitely get some Linux books too now. Thanks again and feel free to post anything else that way come to mind
Well - I can't post anything and everything; some of this you're just going to have to learn the "hard way". BTW - your post about how to dump the output of man to a file, while it can be useful, isn't really something you need to do (unless you really need the file for some reason). The "man" command just reads the "man" files (they are stored elsewhere on the system in a particular "shared" directory); you could just copy those (although they are typically compressed nowadays - on my system, they are gzipped - so you would have to uncompress them first to read them in a text editor or such). If you need to copy/paste the data, most terminal emulators today support copy and paste as well.
Oh - something else about "copy/paste" - while it has gotten better in recent years, it still isn't -completely- unified; there are a couple of "standards" out there - you'll find them fighting against you sometimes. First off, the standard "X window" copy/paste is done by highlighting something, then middle clicking elsewhere to "paste" it (notice there wasn't any explicit copy done). The other standard is to highlight something, then "ctrl-c" and "ctrl-v" (or using the edit menu or whatever to do the analogous thing); sometimes, the "clipboard" that stuff is copied to can be used vice-versa between the two, other times it can't - so you can sometimes do a highlight then "ctrl-c" then position your mouse elsewhere and "middle click" to dump it. Or - you can "highlight" then "ctrl-v" elsewhere to paste the highlight. Other times, you'll find that doesn't work. And in a few cases, you'll find you can't copy/paste something to save your life, and you have to get really creative (typically by using a "third-party" application - like some text editor - that both other apps recognize).
Welcome to the "wild west" of Linux (it's being tamed really slowly - but I wouldn't have it any other way - if I wanted ease of use, compatibility, etc - you know, the boring stuff in life - I'd just use Windows or a Mac)...
Lastly - keep playing and learning the commands; even given what I said above, you still managed to learn a few things. I found that keeping a notebook (one of those black and white composition books, or whatever you think works) was really helpful (and something I still refer to on occasion) - especially for obscure tasks (you can write on a "single line" mini shell programs that can accomplish quite a lot of work - these can be difficult to remember, so when I set one up particularly useful, I write it down for later).
