*MAFIA* Forums
- May 03, 2024, 06:28:54 AM
- Welcome, Guest
News:
Welcome back the Arcade! Play over 100+ games to get the high score and compete against other forum members.
http://www.mafiaowns.com/index.php?action=arcade;sa=list;sortby=a2z;
|
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
8
Here's the dealership my new car came from.
http://www.i-am-bored.com/bored_link.cfm?link_id=18025
[COLOR="Sienna"]EDIT:[/COLOR] I know this one has nothing to do with the other, but it's worth it.
http://www.holylemon.com/FunnyCatJump.html
http://www.i-am-bored.com/bored_link.cfm?link_id=18025
[COLOR="Sienna"]EDIT:[/COLOR] I know this one has nothing to do with the other, but it's worth it.
http://www.holylemon.com/FunnyCatJump.html
10
This morning I woke up. The Bureau of Unifying Mattism (BUM) has decided this was a very bad move. In fact, the quality of life would have rose about 3.1459...% per person. Or 22/3 for those of you who like fractions.
But being the broken, souless creature of habit I am, I went through the motions of life -- school, work, bank, return the videos, grab a bite to eat, straighten up the house, do some laundry, take out the trash, waste away another day of my life. Check, check, and check.
Work was wonderful today. Another 9 1/2 hour day of repetitiveness a trained monkey could handle drunk. And yet I got paid, so I can't complain. Then I came home. Where I sat in the dark. Alone with my thoughts. Writing to you.
See why I said it was a mistake?
I would have made this longer, but I know some of you can't stomach long posts.
Pussies.
But being the broken, souless creature of habit I am, I went through the motions of life -- school, work, bank, return the videos, grab a bite to eat, straighten up the house, do some laundry, take out the trash, waste away another day of my life. Check, check, and check.
Work was wonderful today. Another 9 1/2 hour day of repetitiveness a trained monkey could handle drunk. And yet I got paid, so I can't complain. Then I came home. Where I sat in the dark. Alone with my thoughts. Writing to you.
See why I said it was a mistake?
I would have made this longer, but I know some of you can't stomach long posts.
Pussies.
12
Media / What the fuck?
« on: June 13, 2006, 08:43:41 PM »
First of all, where do you come up with an idea like that? And second, why would you ever actually get the thing so you could practice? Fucking weird people man.
http://www.ebaumsworld.com/videos/conejuggler.html
http://www.ebaumsworld.com/videos/conejuggler.html
14
Flame / Uncle Rahl Wants You!
« on: December 12, 2005, 11:14:13 PM »
That's right, Uncle Rahl needs you! Or rather, his friend could use the assistance. A buddy of mine was in a bit of an edit war on wikipedia with some yahoo who refuses to believe .999 repeating equals 1 when taken to infinite precision. Right now, the page is locked from further edits while a vote is tabulated to determine what the community says. So I'm requesting any of you wiki fiends to go vote for him (have to register first).
The Page
And for those of you who don't believe the statement about .9999 = 1, go here.
Thank you.
The Page
And for those of you who don't believe the statement about .9999 = 1, go here.
Thank you.
15
Spam / Bash Scripting #1
« on: September 22, 2005, 10:12:59 PM »
So . . . I finally got around to hammering out an introductory splurb on bash scripting. For those too few, enjoy.
---------------------------------------------------------
Bash Scripting -- Installment #1
A bash script is essentially a simple, yet powerful programming language that utilizes all the normal shell commands along with a few other additions. In it's most basic state, a bash script is just a file containing a certain set of shell commands like ls, rm, mv, cp, etc. However, these simple scripts can quickly grow more complex when variables, selection statements, and iteration constructs are added.
Each bash script should begin with #!/bin/bash or something similar. This statement tells the OS which shell to use when running the script -- be it bash, sh, csh, etc. Bash tends to be the default on a lot of Linux distros, so it's probably your best bet. If you'd like to check what shell you're using, on the command line, type echo $SHELL. That's your default shell. You can change this by altering the /etc/passwd file (requires root). There will be a line with your username. It should look something like rahl:x:1000:100:Nathaniel Rahl:/home/rahl:/bin/bash If you alter /bin/bash to reflect the location of your favorite shell type, it will default to that.
Now that we've got that covered, let's look at an example script where we utilize a few of the shell commands we've seen. Here, we'll change to a directory and remove all the files in that directory.
01 #!/bin/bash
02
03 cd /home/keelerm/Mafia/Tutorials/Scripting/Bash/example
04 echo "Before remove"
05 ls
06 echo "After remove"
07 rm *
08 ls
Save these commands to some file (like example.sh) and, on the command line, issue the statement chmod u+x example.sh. Then, when you do ./example.sh it should run. chmod u+x gives executable permission to the owner of the file, and ./example.sh calls the script. The .sh in the file name optional, but I recommend it. Extensions are almost always unnecessary in Linux (GIMP and gcc are the only exceptions I can think of), but it is helpful to remind you what program uses the script. It'll become more important if we learn some perl, python, awk, or sed.
Notice how on line 03, we point the script at the directory we're interested in. If we didn't do that, the statements would be executed from wherever the script was stored (which could prove quite painful if we run it with the right permissions). The statment echo just prints whatever is in the quotes. We've seen ls and rm, and I'm sure we remember that * tells the shell to grab everything. Our first script! Excellent. And if that wasn't cool enough, we can have variables too! That's wild.
A variable is simply a meaningful name for a location in memory containing some data. Instead of seeing 0x0A1C93 or some shit, we get myVarName which is a lot easier to remember. For those of you familiar with other programming languages, please note that there are no declarable variable types for a bash variable. It simply is what it is, and the OS has to worry about that when the time comes, not us. For those of you who haven't programmed before, all that means is that any variable can contain an integer, character, a string, whatever and we don't have to tell the computer what type it is going to be before we assign it that value. With that said, let's declare a variable mafiaPwns to some string.
mafiaPwns="*MAFIA* [pwns] n00blet"
NOTE: We see there are no spaces on either side of the equals sign. This is important to follow. Remember, the shell is the one that actually executes these statements, and the shell parses (or determines) commands by white space. If we type mafiaPwns = "MAFIA* [pwns] n00blet", the shell reads mafiaPwns, looks for that command, fails, and throws an error. When it sees it without a space, it realizes we're declaring a variable.
If we want to see the value we saved in a variable, we can issue an echo statement, like this
echo $mafiaPwns
If you want to get information from the keyboard and save that to a variable (called userInput), try read userInput. The input will cease when the user hits enter.
The variable name is preceded by $ when we want the value of the variable, like in the echo statement. But if we're trying to save a value to the variable, we would want the memory location which is all the variable name is -- just an alias for a memory address.
Aside from the variables which you can declare yourself, each shell comes with a preset group of variables. We've seen one already in this tutorial -- did you catch it? Remember $SHELL? That's a standard shell variable which stores the path to the shell the given user utilizes. Below are just a few of the default variables that might be of interest.
$USER - Tells you who you are logged in as (more important than you might first think)
$UID - The unique user ID number (found in /etc/passwd)
$PWD - Present Working Directory. Where are we looking at?
$PATH - A list of directory paths containing commonly used commands. This prevents the user from having to fully qualify commands they use on a regular basis. For example, without having a user's PATH variable include /bin, everytime you tried to issue an ls command, you would have to type /bin/ls to get it to work.
If your script alters any of these variables, they only stay changed until the script ends. Once it's done, it reverts back to it's previous state. If you want to keep the changes, issue the statement export after the final change. So, if I wanted to change my PATH variable, I would have
#!/bin/bash
PATH="PATH:/path/to/new/place"
export PATH
And I think that's quite enough for one tutorial. More to follow.
---------------------------------------------------------
Bash Scripting -- Installment #1
A bash script is essentially a simple, yet powerful programming language that utilizes all the normal shell commands along with a few other additions. In it's most basic state, a bash script is just a file containing a certain set of shell commands like ls, rm, mv, cp, etc. However, these simple scripts can quickly grow more complex when variables, selection statements, and iteration constructs are added.
Each bash script should begin with #!/bin/bash or something similar. This statement tells the OS which shell to use when running the script -- be it bash, sh, csh, etc. Bash tends to be the default on a lot of Linux distros, so it's probably your best bet. If you'd like to check what shell you're using, on the command line, type echo $SHELL. That's your default shell. You can change this by altering the /etc/passwd file (requires root). There will be a line with your username. It should look something like rahl:x:1000:100:Nathaniel Rahl:/home/rahl:/bin/bash If you alter /bin/bash to reflect the location of your favorite shell type, it will default to that.
Now that we've got that covered, let's look at an example script where we utilize a few of the shell commands we've seen. Here, we'll change to a directory and remove all the files in that directory.
01 #!/bin/bash
02
03 cd /home/keelerm/Mafia/Tutorials/Scripting/Bash/example
04 echo "Before remove"
05 ls
06 echo "After remove"
07 rm *
08 ls
Save these commands to some file (like example.sh) and, on the command line, issue the statement chmod u+x example.sh. Then, when you do ./example.sh it should run. chmod u+x gives executable permission to the owner of the file, and ./example.sh calls the script. The .sh in the file name optional, but I recommend it. Extensions are almost always unnecessary in Linux (GIMP and gcc are the only exceptions I can think of), but it is helpful to remind you what program uses the script. It'll become more important if we learn some perl, python, awk, or sed.
Notice how on line 03, we point the script at the directory we're interested in. If we didn't do that, the statements would be executed from wherever the script was stored (which could prove quite painful if we run it with the right permissions). The statment echo just prints whatever is in the quotes. We've seen ls and rm, and I'm sure we remember that * tells the shell to grab everything. Our first script! Excellent. And if that wasn't cool enough, we can have variables too! That's wild.
A variable is simply a meaningful name for a location in memory containing some data. Instead of seeing 0x0A1C93 or some shit, we get myVarName which is a lot easier to remember. For those of you familiar with other programming languages, please note that there are no declarable variable types for a bash variable. It simply is what it is, and the OS has to worry about that when the time comes, not us. For those of you who haven't programmed before, all that means is that any variable can contain an integer, character, a string, whatever and we don't have to tell the computer what type it is going to be before we assign it that value. With that said, let's declare a variable mafiaPwns to some string.
mafiaPwns="*MAFIA* [pwns] n00blet"
NOTE: We see there are no spaces on either side of the equals sign. This is important to follow. Remember, the shell is the one that actually executes these statements, and the shell parses (or determines) commands by white space. If we type mafiaPwns = "MAFIA* [pwns] n00blet", the shell reads mafiaPwns, looks for that command, fails, and throws an error. When it sees it without a space, it realizes we're declaring a variable.
If we want to see the value we saved in a variable, we can issue an echo statement, like this
echo $mafiaPwns
If you want to get information from the keyboard and save that to a variable (called userInput), try read userInput. The input will cease when the user hits enter.
The variable name is preceded by $ when we want the value of the variable, like in the echo statement. But if we're trying to save a value to the variable, we would want the memory location which is all the variable name is -- just an alias for a memory address.
Aside from the variables which you can declare yourself, each shell comes with a preset group of variables. We've seen one already in this tutorial -- did you catch it? Remember $SHELL? That's a standard shell variable which stores the path to the shell the given user utilizes. Below are just a few of the default variables that might be of interest.
$USER - Tells you who you are logged in as (more important than you might first think)
$UID - The unique user ID number (found in /etc/passwd)
$PWD - Present Working Directory. Where are we looking at?
$PATH - A list of directory paths containing commonly used commands. This prevents the user from having to fully qualify commands they use on a regular basis. For example, without having a user's PATH variable include /bin, everytime you tried to issue an ls command, you would have to type /bin/ls to get it to work.
If your script alters any of these variables, they only stay changed until the script ends. Once it's done, it reverts back to it's previous state. If you want to keep the changes, issue the statement export
#!/bin/bash
PATH="PATH:/path/to/new/place"
export PATH
And I think that's quite enough for one tutorial. More to follow.
Pages: [1] 2