Radified Community Forums | |
http://radified.com/cgi-bin/yabb2/YaBB.pl
Rad Community Technical Discussion Boards (Computer Hardware + PC Software) >> PC Hardware + Software (except Cloning programs) >> Using the Unix/Linux shell command-line http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1247608529 Message started by Rad on Jul 14th, 2009 at 4:55pm |
Title: Using the Unix/Linux shell command-line Post by Rad on Jul 14th, 2009 at 4:55pm
The following are notes I made for myself during my study of how to use the Unix/Linux shell command-line (a study which is still in progress, so there will be more):
Linux.Shell ! = not ? = single-character wildcard * = multi-character wildcard cat = displays entire contents of text-based file more = displays single page of text-based file, either 1 line (enter key) or 1 page (space bar) at a time.q = quit [___] square brackets displays single character of any characters contained within square brackets ls = lists/displays contents of directorys ls -F indicates directories with a slash beside listing ls -l files details (long listing) ls -r recursive, lists contents and includes files in all subdirectories ls -C arrange files/directories in Columns ls -d * = list all files but no directories ls [a-z] * lists all files beginning with a-thru-z head = displays first 10 lines of a text-based file tail = displays lat 10 lines of text-based file can use any of commands to display contents of MULTIPLE files pwd = Print Working Directory, tells us where we are sh = Bourne shell = first shell bash = Bourne Again SHell = usually comes with Linux = free ksh = Korn SHell (by David Korn) = not free/open zsh = Z SHell csh = C SHell possible to write scripts with bourne shell as interptrter = shell scripts therefore some people think of the bourne shell as a programming language, or a scripting language, not just an interactive shell to start programs root = user name with full system priviledges uname = details about what machine currently using (e.g. linux) uname -a = more info about machine you're using ps = tells name of all programs currently running, including what shell you're running cal = calendar cal 2009 = whole year cal 7 2009 = calendar for july 2009 passwd = change password syntax = program-name [options] [arguments] . = current directory .. = parent directory man = manual pages man prog-name e.g. man cal [use page-up, page-down] q to quit/exit whatis - used to searc h for keywords on various functions exit = log out or ctrl+d / = root directory (called "slash") typing "cd" <enter> takes us to home directory. ~ is shorthand for user's home directory characters okay to use for file names: a-z, A-Z, 0-9, .,@ _-:+ mv = move or rename file, e.g. mv binfile binfile1 rm = remove or delete file file = makes a guess as to a file's contents, e.g. file * (for all files) diff = compares 2 text files cmp = compares 2 binary files, will also compare text files, but diff is much better tool. cmp only gives 1 line of output, telling us WHERE files differ. 04-06 > Copy, Moving & Renaming Files cp = copy e.g cp file1 file2 creates a duplicate of file1 named file2 in same directory can list multiple files to copy .. e.g cp file1 file2 file3 new_directory if last argument = a directory, all files listed are copied there e.g. cp *.html ~/gfx copies all hyml files into gfx directory mv = move mv is also used to rename files .. e.g. mv file1 file2 renames file1 as file2 to a different directory .. mv *.html /tmp moves all html files to tmp directory 04-07 > Deleting Files rm = remove warning .. unix/linux does not undelete, rm carefully read-only files will prompt for confirmation for delete .. need to answer y for yes to delete no messages are provided to verify file(s) was(were) deleted .. as with most unix commands cannot delete files you have no authorization for, or files that belong to someone else rm -i (interactive) asks for y/n confirmation before deleting -i option useful if you have, say, 20 files in a directory, and you wanna delete some of them. can rm -i * and answer y to only those files you wanna delete. but if you forget the -i, then rm * will delete ALL files in that directory. rm -f (force) option tells unix not to ask for any confirmation, and if file doesn't exist, display no message to that effect rm -r (recursive) is dangerous. use with extreme caution. deletes all subdirectories and files contained in those subdirectories, which can be thousands of files rm -r = very powerful tool 04-08 > Wildcards any file that begins with a . (period) is a hidden file hidden files are not displayed with regular ls not match by wildcards ? or * .. e.g rm * will delete no hidden files ls-a (all) WILL display hidden files hiddden files are not special (just hidden) usually config files are hiddden, such as .profile (log-in config) and .exrc (vi config) .. set-and-forget-type files. but, if you wanna back-up all files in a directory, hiddrn files will not be backed up with normal methods. or, if you wanna rmdir, have to first do a rm *, but this will not delete hidden files, so can't delete directory this way. 04-09 > Shortcuts for Working & Parents Directories . = alias or shortcut for "the current directory" e.g. mv /tmp/*.html . moves all html files from tmp directory to the current directory (here) .. = alias for the "parent directory" e.g. "mv *.html .." moves all html files to the parent directory, even if you don't know what the parent directory is. "cd .." takes us to the parent directory. this will take us all the way back to the root ( "/" slash) directory. both the . and .. aliases are treated as hidden files 04-10 > Relative vs Absolute paths relative paths do NOT begin with a slash i.e. usr/rad/gnarly/july/cool_01.txt (if you were in the root / directory) absolute paths DO begine with a slash /home/rad/public_html/cgi-bin/yabb2/YaBB.pl 04=11 > Working with Directories mkdir = make new directory .. i.e. mkdir newdir rmdir = remove directory .. i.e. rmdir newdir .. first navagate to its parent directory (cd ..) directory must be empty for rmdir to work. first navigate back into directory, then rm * (or file names) or rm -i * can also use "rm -r dir_name" (very powerful command, use with caution) directories can also be renamed and moved using mv command |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 14th, 2009 at 5:01pm
MORE:
04-12 > Finding Files find = powerful program .. long man page .. i.e. "find top-directory" e.g. "find /home/rad/public_html" e.g. find /home/rad -name filename.html -print some, not all, implementatitions of unix require you to enter the -print option or nothing will show up on screen, even if some files are present and matched. the -print option is to print to screen, not a printer important - when using wildcard characters, must enclose argument in single quotes. e.g. "find . -name '*.txt' -print" doesn't hurt to enclose ALL file_name arguments in single quotes. don't forget to include the -name option when looking for a file by name. (easy to forget .. e.g. "find . report.txt -print" can also find files based on other criteria besides name, such as the file owner, permissions, type, date, size can do other actions besides print-to-screen .. e.g > (an advanced manipulation of files) find . -type f -exec rm -i {} /; 04-13 > Archiving Files tar gzip and compress commands/programs can all compress files tar and cpio can write to offline media, such as tape drive tar stands for "Tape ARchive" to archive an entire directory, go to that directory and enter "tar cf newfilename.tar ." the period . represents the current/working directory cpio = industrial-strength version of tar, trickier to use, more thorough. cpio can specify more detailed options e.g. "find . -name '*.html' | cpio -o > archive.cpio (or > dev/tape0, or > /dev/fd0) in previous example, "." refers to present working directory, | = 'pipe' or pipe to, -o refers to output, > refers to 'send to' in order to read FROM the cpio archive: cpio -i < /dev/fd0 in previous example, the < sign means 'read from' and -i stands for 'input' can compress tar or cpio files e.g "compress archive.cpio" .. becomes archive.cpio.Z capital Z indicates a compressed file to un compress use "uncompress archive.cpio.Z" may also have to untar this file (tar -xf) if it was tarred. 05-01 Security Unix is a multi-use O/S (which is why we need security), so we share our system with others. Each user has separate access priviledges for system resources (e.g. files, directories, drives, devices, etc.) "who am i" reveals the user name you're logged in as. "pts" is the terminal number. "id" command also reveals user name, plus user number, plus group id, plus all groups we're a member of (e.g. sales group, managers groups, etc.) "gid" (group id) = current group logged is as, while "groups" = all groups we're a member of. "newgroup" command lets us switch to a different group that we're a member of su = super user can log-in as a different user if you know their user name and password, e.g. > "su newuser" which will present a prompt asking for newuser's password. typing "exit" takes you back to original user log-in. if you enter this log-in with a "-", such as "su - newuser" this will simulate full log-in as neweser, and take you to newuser's home directory. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 14th, 2009 at 6:53pm
Lots of good info here on commands available in the Linux shell. You've also got some regular expression stuff mixed in. Maybe when you are done, if you don't mind, I'll re-arrange things a bit so the organization is more clear to someone looking at it fresh and integrate it into my Linux guide. The guide is currently a little weak on helping new users navigate the shell.
|
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 14th, 2009 at 7:11pm
Oh yeah, certainly. Feel free to have at it as you see fit.
Not sure what you mean by regex stuff. That was the stuff Nigel suggested I focus on when we discussed PHP. (I miss Nigel's wisdom & experience.) |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 15th, 2009 at 12:23am Rad.in.UbuntuVM wrote on Jul 14th, 2009 at 7:11pm:
Rad wrote on Jul 14th, 2009 at 4:55pm:
This is regular expression stuff. You use regular expressions to look for patterns in text. Regular Expressions are very powerful and useful. The basics are easy to learn, but the advanced stuff isn't necessarily intuitive. It's easy to get confused working with complicated regx. |
Title: Re: Using the Unix/Linux shell command-line Post by NightOwl on Jul 15th, 2009 at 9:47am
@ MrMagoo
Quote:
Just a suggestion, if it's not already your intention--leave the *original* as is, and add a reference (link) to your edited version (later in this thread--or a separate thread--whichever makes sense) so one can compare the before and after. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 15th, 2009 at 6:33pm NightOwl wrote on Jul 15th, 2009 at 9:47am:
Yup, will do. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 20th, 2009 at 12:46pm
From Nigel:
Quote:
|
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 20th, 2009 at 12:50pm
05-02 File Protection
each file/directory has: 1. an owner (user name) 2. a group (group name) 3. permissions (access rights for various parties to the file/directory) Three sets of permissions: 1. owner (access priviledges) 2. group (access priviledges) 3. everyone else (access priviledges) Only the owner can change access priviledges (not group members) "ls -l" shows permissions along with owner & group r = read - for files, this gives pemission to view the file, using "cat" for example) w = write (for files, this permission allows you to modify the file, using a text editor for example) x = execute (for files, this only makes sense if the file is a program, such as binary program or shell script. Possible to set x permission for non-program files, but this yields no benefit) For folders/directories: r allows you to view contents of directory, using "ls" for example w allows you to create or delete files in directory. 'w' setting is most important for directories, and can represent a security risk, because it is possible to remove w permission on the file, yet grant w access on the directory. To protect a file, need to "turn off the w bit" on *both* the file and directory x (for folders/directories) grants access to (can go there) using "cd" for example permission listing contains 10 slots e.g. -rw-----r-- says this is a file (not a directory) that gives read and write permission to the owner, and read permission to everyone else first slot indicates whether file (-) or directory (d) next 3 slots indicate rwx permissons for the owner next 3 slots indicate rwx permissions for the group last 3 slots indicate rwx permissions for everyone else the "root"user will never see the words "Permission denied" cuz root user has permission to do anything and everything |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 20th, 2009 at 1:49pm
05-03 - Changing File Permissions
chmod (CHange MODe) = program/command that changes file & directory permissions Two methods: 1. Symbolic mode (uses typically used by beginners, easies to learn, cuz it uses letters, but can be long-winded) 2. Numeric mode (typically used by those more comfortable with chmod) syntax > "chmod permissions filename(s)" e.g. symbolic mode > "chmod u+w file1" adds (+) write permission (w) to owner (u) for file1 For symbolic mode (most common letters): u = owner g = group o = other a = all + = add - = remove = = set (when setting, only permissions specifed are set, others are turned off) Specify who will get permission first (u, g, o, a), then the action (+, -, =), lastly the permission itself (r, w, x) Can set multiple permissions in same command (separated by a comma), such as "chmod uo+w,u-rx file1" Setting all 9 permissions using symbolic mode can be time consuming, so numeric mode is more common Numeric mode (used by experienced Unix users): 3 digits sets all 9 permissions r = 4 w = 2 x = 1 no permissions = 0 r+w = '6' (4+2) r+x = '5' (4+1) r+w+x = '7' (4=2=1) e.g. "chmod 755 file1" gives full permissions (7) to owner of file1, plus r+x permissions (5) to group and everyone else e.g. "chmod 640 file1" gives r+w permissions to owner of file1, plus read perm to group, and no permissions to anyone else e.g. "chmod 070 file1" gives full permissions to the group associated with file1, with nobody else getting any permissions common settings for data files: 444, 644, 664 & 666 common settings for programs 750, 755, 777 (not user very often) common settings for directories: 755, 775, 777 (be careful about giving write perm for directories) |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 20th, 2009 at 2:04pm
05-04 - Changing File Ownership (much simpler than changing permissions)
chown (CHange OWNership) = command/program to change file ownership syntax > "chown owner filename(s)" e.g. > "chown spanky file1" gives ownership of file1 to spanky e.g. > "chown ralph *.html" gives ownership of all html files to ralph Ownership has nothing to do with where the file is located Just because a particular file may be sitting in a directory you own, doesn't necessarily mean you own the file. Only the owner can change permissions and ownership. Once you change ownershipo, you can't change it back, cuz you no longer have ownership |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 20th, 2009 at 2:15pm
05-05 - Changing File Group (very simple)
chgrp (Change GRouP) = command/program to change group e.g. "chgrp sales report*" gives certain permissions tp group named 'sales' for all files that begin with string 'report' newgrp (NEW GRouP) = command/program to change your 'current' group ID, used when you get 'Permission denied' for files assigned to groups you are part of. e.g > "newgrp marketing" changes your current group to 'marketing' |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 20th, 2009 at 2:34pm
05-06 - Dangerous Security Loophole
Occurs when a particular file has its write permission removed (444 or 666), but the directory that file sits in has write perm granted (666 or 777) e.g. > dir1 > drwxrwxrwx file1 > -r--r--r-- (read only) everyone has access to directory that read-only file1 sits in Here's how to modify file1: copy file1 to another filename .. such as file2 (now you have permission of/for file2 cuz you are its owner) modify file2 (since you now have ownership of file2. If you don't have write perm of file2, you can give yourself write perm, cuz you are its owner) rm file1 (possible since dir1 is writable by anayone .. here is where the glitch lies) after file1 removed, mv file2 file1 (to make file2 become file1) change permission of file1 to original owner difficult to tell file1 has been modified, only it "Last modified" time/date stamp will have been updated Moral of the story > pay attention to directory permissions. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 22nd, 2009 at 5:09pm
06-01 - Combining Programs (Pipes, Filters & Redirects)
"Output" = what you see printed on the screen by the program/utilty Not all programs produce output ls does produce output cd, cp, mv, rm, mkdir all produce no output (except if there is an error) output can redirected to either: 1. a file (easy to do) 2. another program (a little trickier) ">" sends output to a file .. can be extremely useful e.g. "ls -l > listing.txt" sends the output of ls -l to a file named "listing.txt" "|" (called a 'pipe') sends output to another program who = program lists all users currently logged into the system but no program tells number of users currently logged into the system but we can combine two simple programs wc = word count .. counts lines, words, and/or characters of any input it receives from programs or files specified. e.g. "who | wc" gives output of wc program that was received from who program Any two prgrams can be connected by the 'pipe' symbol, long as: 1. the first program produces output 2. the second program takes input Upon command, Unix will start both programs and then 'pipe' the output of the first into the input of the second. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 22nd, 2009 at 6:44pm Rad.in.UbuntuVM wrote on Jul 22nd, 2009 at 5:09pm:
It is helpful to understand that the shell defines 2 different types of output, "output" and "error". Both can be redirected (like you mention,) but they can be controlled separately. The default for most programs is to send output to the shell's "stdout" and to send errors to "stderr". stdout and stderr are usually both configured to go to the tty (or vtty, if you are logged in remotely) so the effect is that the output is printed on the screen. You can redirect them independantly to any file. What is important to remember here is that almost everything in Linux is a file. Network sockets, hardware devices, and other tty's can be treated as files (and in many ways are treated as files by the kernel.) So, your options aren't limited to regular text files. Rad.in.UbuntuVM wrote on Jul 22nd, 2009 at 5:09pm:
This can be as easy or as complicated as you want to make it, but is incredibly useful. For example, say a directory has a LOT of files. You are looking for a text file, but you aren't sure exactly what it is called. You could use: ls /the/directory | grep *.txt to see all the files named something.txt in that directory. This should make it easier to find the one you are looking for. Now, say there are a lot of text files in that directory, and the results scroll off the page. You might add another pipe to view the output a page at a time: ls /the/directory | grep *.txt | more So, you can see, we can make this as complex as you want. I've used something like this before: ps aux | grep baduser | awk '{print $2}' | xargs kill -9 This would find all running programs owned by baduser, extract the process id (pid), then kill them (end them.) Like I said, it can get as complex as you want. I know some admins who work on huge (200 CPU) Solaris servers who would think that example is child's play (and it really is, if you break it down and learn the individual commands.) |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 22nd, 2009 at 7:24pm MrMagoo wrote on Jul 22nd, 2009 at 6:44pm:
Didn't know such animals existed. All that power. there are some prgms i keep hearing about, such as sed, grep, awk (i think), but i am not there yet. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 22nd, 2009 at 7:31pm
06-02 - Input (Not many programs take input)
By default, programs take their input from the keyboard Filters can take input from either: 1. keyboard 2. file 3. another program to feed input to a program from a file, we use "<" e.g. "wc < file.txt" the "<" sign tells the shell to feed the contents of the file named "file.txt" into the wc program can also write "wc file.txt" In this case, the file.txt is an argument wc = an example of a 'filter' |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 22nd, 2009 at 8:09pm Rad.in.UbuntuVM wrote on Jul 22nd, 2009 at 7:24pm:
I use grep daily. I use awk on occasion. I've never used sed. That's not to say it isn't useful - there are several times it could have been helpful - it just doesn't happen often enough that I have learned how to use it. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 22nd, 2009 at 10:50pm
06-03 - Standard Input and Standard Output
Input: 1. Keyboard 2. File 3. Program Output: 1. Screen 2. File 3. Program * Unix philosophy: The people who designed Unix utilities created many simple utilities that can be joined together as necessary. * They provided the Unix utilities as building blocks that can be put together and used in more complex tasks. * This roll-your-own approach is the foundation of Unix shell scripting and is a powerful way of specifying tasks. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 22nd, 2009 at 11:39pm
06-04 - Intro to Filters
1. Takes standard input (from keyboard, file or another program .. after the program has started) 2. Processes data inputted 3. Produces output based on input wc is a filter (word count). It does all 3. Filters are text processing devices |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 23rd, 2009 at 12:35am
06- 05 - Common Filters
more (pagination) e.g. "who | more" or "more file.txt" grep (removes lines that do not contain certain text) [ grep is so useful that an entire module will be devoted to it. ] sort (sorting) e.g. "who | sort" or "sort file.txt" (sorts alphabetically) or "who | sort | more" [ when sorting a file, only the on-screen data is sorted. The file itself remains unchanged. ] wc (counts lines, words and/or characters) tee (duplicates by writing to both the screen and a file) e.g. "who | tee wholist.txt" sed (basic editing .. a rather complex filter, could take an entire chaper, more powerful processing than sort or grep) awk (most compex & powerful of all filters, does anything you might want, could take an entire course) [ awk has its own programming language ] cat (simplest of all filters, involves no processing, echoes input to screen) e.g. "who | cat" or "cat file.txt" |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 23rd, 2009 at 1:19am Rad.in.UbuntuVM wrote on Jul 23rd, 2009 at 12:35am:
This is oversimplified. I'm going to add a little detail. cat was originally designed to to conCATenate multiple files. In other words, the results of 'cat file1 file2 file3' should be a single file containing each of the 3 input files one after another. Now, that by itself isn't often incredibly useful, and there are lots of ways to achieve the same effect. However, by default, cat sends its output to stdout, which is usually the tty you are on, which means the text gets printed on the screen. So, cat often gets used to simply dump text onto the screen. While this is useful, it is a side-effect of its original design. I do use it often for this simplified purpose, but it always give me a slight twinge of guilt. It feels like I'm somehow cheating since I never use it for what it was actually intended for. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 23rd, 2009 at 7:43pm
06-06 - Searching for Text in Files (grep)
grep is a particularly useful filter grep wll print all lines that contain the text specified actually (to be specific) grep REMOVES lines that do not contain the text specified so grep is a true FILTER, by filtering out all lines that don't contain the text specified syntax: "grep pattern filename(s)" pattern = the text you search for e.g. "grep rad *.html" will display all the lines that contain the word 'rad' in all the html files grep uses its own set of wildcards grep's wildcards are consistent with all program's in Unix that use Regular Expressions, such as vi and sed. the shell does NOT use Regular Expressions Regular Expressions have their own particular set of wildcards. use single quotes to enclose any searched-for terms that contain special characters. e.g. "grep '<h3' index2.html" - The < sign is a special character. If you're searching for only regular text words (with no special characters), single quotes are not required. But good idea to enclose EVERYTHING you search for in grep inside single quotes when searching for text thru a big set of directories & subdirectories, or even the entire computer, then good idea to use grep in conjunction with find. e.g "find . -name '*.txt' -exec grep 'hello' {} \;" notice no piping going on. Simply using 2 programs in conjunction with each other. Read the grep man pages, particularly in relation to the Regular Expressions. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 24th, 2009 at 12:15am Rad.in.UbuntuVM wrote on Jul 23rd, 2009 at 7:43pm:
There is no piping going on because the find command has the '-exec' option, which is being used here. It's a really nice option, allowing you to do things like: find /var/log -atime +90 -exec rm \; which finds any file in the /var/log directory which hasn't been read in more than 90 days and deletes it. You could achieve a similar effect by piping the output of find to xargs (find /var/log -atime +90 | xargs rm) but the -exec option makes it a little more streamlined. Rad.in.UbuntuVM wrote on Jul 23rd, 2009 at 7:43pm:
The man pages probably won't do Regular Expressions justice. They are worth some study on their own. There aren't many guides on the Internet that give a clear introduction to Regular Expressions. Here are a few I found in a brief search, and my sincere thanks would go out to anyone who can find anything more clearly written: http://www.amk.ca/python/howto/regex/ http://www.regular-expressions.info/tutorial.html The Wikipedia example page is helpful for learning: http://en.wikipedia.org/wiki/Regular_expression_examples and here is a user-contributed library: http://regexlib.com/ The best book, for those who have time, money, and a need to *really* understand this, is by O'Reilly: http://oreilly.com/catalog/9780596528126/ O'Reilly has outstanding books on many Unix and computer science subjects. I've read several, and found them all worth my time. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.Test on Jul 24th, 2009 at 5:18pm
I've been hearing about Regular Expressions more and more. And it seems many languages use/support them, no? (such as PHP)
So it seems time spent learning RegEx would be time well spent, no? Nigel was the one who first suggested I pay particular attention to RegEx. I seem to learn best with the multi-pass approach .. first a quick review to get a general idea of what's what. Then a more involved look/see. Progressing with breaks in between to allow for 'settling' and development of a format for more involved learning. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 24th, 2009 at 5:34pm Rad.Test wrote on Jul 24th, 2009 at 5:18pm:
Yup. PHP, Perl, Ruby, grep, sed, and too many more to list. Regular expressions are very useful and very portable. Rad.Test wrote on Jul 24th, 2009 at 5:18pm:
I think that Nigel also made a point that with PHP, everything you are doing breaks down to processing text patterns if you break it apart far enough. Therefor, if you understand RegEx, you will have an idea what is going on underneath the PHP code you write. Rad.Test wrote on Jul 24th, 2009 at 5:18pm:
I've found that one of my strongest strengths is understanding how I learn. When I can find material that matches up with my learning style, I can absorb an incredible amount of information quickly. Unfortunately, finding material that fits my unique learning style often takes almost as long as working through said material, so I have to balance my time looking for the right way to learn with actually learning. Of course, teaching something and getting practical experience in it are the BEST ways to learn, but both can be time consuming. Maybe someday we'll make a whole thread on it, but for now, you might find the cone of learning interesting: http://docs.google.com/gview?a=v&q=cache:C9L5WXRRopIJ:www.public-health.uiowa.edu/icphp/ed_training/ttt/archive/2002/2002_course_materials/Cone_of_Learning.pdf+cone+of+learning&hl=en&gl=us I'm not sure if I think it fits me 100%, but it does put learning/teaching styles into perspective. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 24th, 2009 at 7:01pm MrMagoo wrote on Jul 24th, 2009 at 5:34pm:
I would call that a 'pyramid' .. of learning. Suks that reading seems to yield the least, with only 10%. The Head First series of books specifically addresses the concept of learning and begins each text with a chapter on why the book is designed the way it is. http://blogs.radified.com/2007/07/learning_theory_head_first_book_series_oreilly_xhtml_css.html I enjoy learning about learning. I normally read with a pen. The mere act of deciding what to underline (the important parts) and what to leave alone seems to improve retention. By getting me actively involved. Really important ideas/concepts get a star. Things I'm not clear on get a question mark. Things worth pondering get a "Hmmm" (in the margin) Etc. From what I've read, we should try to be *emotionally* involved in learning, as emotions seem to aid retention. Being RELAXed is also another concept I've heard of .. as is "frequent breaks" (as we learn better at the beginning & end of a learning session). But best of all, I think, is being INTERESTED in the subject matter. No? If you are lost in the wild, and hungry, I bet a book on edible plants would be very easy to read. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 24th, 2009 at 7:08pm MrMagoo wrote on Jul 24th, 2009 at 5:34pm:
Not sure exactly what you are referring to. Example? |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 24th, 2009 at 7:24pm
Is RegEx like a search prgm, or just the characters used in the strings that you search for?
In other words, do you have to use RegEx in conjunction with another prgm? |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 24th, 2009 at 7:29pm
06-07 - Standard Error
Each program produces 2 separate sets of output They both go to the screen by default Do it appears to be 1 set First set = standard output Second set = standard error Standard error contains any error messages a program might've produced. Standard error can go to either: 1. screen (default output) 2. file (can't go to another program) To redirect standard error to a file, use "2>" (no space between 2 and >) btw - standard output can be redirected to a file by using "1>" but the 1 is assumed by default, so nobody uses it. So .. any command's output can be redirected to 2 separate files, if necessary. Or 1 can go to a file, while the other goes to the screen /dev/null = special file, like a black hole. anything sent there disappears into thin air. e.g. "find / -name xyz 2> /dev/null" redirects all error messages (many "Permission denied" messages) to black hole /dev/null and displays only valid finds (files or directories named 'xyz'). This was the most boring and seemingly useless module yet. While good to know, can't see how I would ever actually use this info. next one looks better > Process Control |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 25th, 2009 at 12:31am |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 25th, 2009 at 3:01pm Rad.in.UbuntuVM wrote on Jul 24th, 2009 at 7:24pm:
Regular Expressions are arbitrary patterns. So, you could look for 2 numbers, followed by any number of letters. Or, you could look for the letters "betr" at the beginning of a word or the beginning of a line. You use a regular expression to describe the pattern you are looking for. Rad.in.UbuntuVM wrote on Jul 24th, 2009 at 7:24pm:
Correct. Regular Expressions are just patterns. You need some program to search for the program you are describing with the regular expression. grep is the best known such program. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 25th, 2009 at 3:13pm Rad.in.UbuntuVM wrote on Jul 25th, 2009 at 12:31am:
I appreciate that Nigel keeps us on our toes even tho he chooses not to participate directly. From the article: Quote:
When I first heard of the cone, I understood that it came out of research done at Arizona State. Even then, I didn't take the numbers literally (or it would have seemed to be a complete waste of time to read anything at all!) It's neat to learn that the original author didn't intend it to be taken any more seriously than I did anyway. To me, its more about the different types of learning and that we need to be aware of the style and type of learning we are using at any particular moment, along with the effect it's having (or more importantly - not having.) Send my thanks to Nigel for making the distinction. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 25th, 2009 at 3:21pm MrMagoo wrote on Jul 25th, 2009 at 3:13pm:
Yeah, he'll drop me an email from time to time. Chock-full of techie-goodies, which I usually have to read 3 times, cuz there's so much there. Quote:
BTW - have you noticed "The Shadow" has 'disappeared'? (I kinda made a funny there.) He sent me a note saying 'Bye' a month or two ago. Why did he leave? Only 'TheShadow' knows. =) http://www.mysterynet.com/shadow/ |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 25th, 2009 at 3:48pm
07-01 - Process Control
Process = running program (emphasis on 'running') There is only one ls program, but if 5 users are currently using the ls program, then there are 5 ls "processes" running. A program becomes a process by being loaded into memory and started (often by the shell, which is a process itself). Every process is assigned a unique ID (PID) from 1 to 30000. Each started PID gets the next sequential number. ps = command that shows processes that are running (for the current log-in session only). options "ps -u username" shows all processes for that user can use this command option to snoop on other users to see what they're running. ps -f and ps -l options both provide more details (for current log-in session only). -e displays every process on the system PPID = Parent Process ID = the PID of the program that started the process .. can be the shell many times TTY = Terminal number the process/program is running on. Time = CPU time in seconds that process has uses, which helps determine how much load a particular process is placing on the system. "ps -fu username" gives MORE info about a particular user "ps -e | wc -l" (piped to wc -l) tells HOW MANY proceses are running "ps -e | grep vi" (piped to grep) shows how many users are running vi (-f not used so can't tell who they are) |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 25th, 2009 at 4:56pm
07-02 - Running Commands Asynchronously
Asynchronously = process runs in the background Means the shell does not wait until process is done before presenting you with another prompt Particularly useful if a process will take a long time to run Accomplished by appending an '&' at the end of the command line. Ctrl-c interupts running processes. e.g. "sleep 3600 &" 3600 = number of seconds = 1 hour sleep = a program that does absolutely nothing ("sleeps"), but does it for an arbitrary length of time (in seconds). "sleep 10" will give you back your prompt in 10 secs. Shell will notify you when background process is done by writing a single line of text to the screen. Can run as many background processes as you like. The IS a limit but it is a very large number, up in the hundreds of program/processes. Proviso #1-> Commands that take standard input should never be run in the background. You CAN run them (commands that take standard input), but it will error at point where it pauses to collect input from keyboard. Because you can't type info into a program that is running in the background. Proviso #2 -> It's possible to run a program that produces standard OUTPUT (or error) in the background, but .. .. that program will spit its output onto the screen regardless of whatever else you might be doing. You might be typing a long command or in the middle of editing a file. This can be very annoying. So its a good idea to redirect this output to a file (or /dev/null). Proviso #3 -> Any time you log-out, all your processes that you started will be terminated. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 25th, 2009 at 8:27pm Rad.in.UbuntuVM wrote on Jul 25th, 2009 at 4:56pm:
Its not that simple. If you log out of a shell, any programs running in that shell will terminate. Any programs you started in a different shell will keep working, as will any programs not tied to a shell. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 25th, 2009 at 8:30pm Rad.in.UbuntuVM wrote on Jul 25th, 2009 at 3:21pm:
I had noticed. I also noticed we don't miss his input nearly as much as we miss Nigel's. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 25th, 2009 at 10:05pm MrMagoo wrote on Jul 25th, 2009 at 8:30pm:
:) i hear ya. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 25th, 2009 at 10:06pm
07-03 - Killing Processes
kill process-id can't do "kill ls" cuz you may have several ls's running. e.g "kill 2532" do a "ps" to determine Process ID # running use kill only as a last result, cuz killing a process can have unexpected results. for example, it might be in the middle of updating a database if you kill it, the database might become corrupt you can only kill processes you have PERMISSION for root superuser can kill anything. some programs can take 10 secs to die, so be patient. some programs are designed to ignore the kill command if the process won't die: "kill -9 process-id" no program can be designed to ignore the '9' signal kill -9 kills a program immediately, and does not give it a chance to do a normal shutdown. so use kill -9 only as a last resort. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 26th, 2009 at 4:44pm
07-04 - Jobs
Both Bash and the Korn shell (ksh) provide further control of the running processes (not the case with the standard Bourne shell .. sh). Bash and ksh allow you to pause or suspend a running program. The correct terminology is "stop" This can be helpful if you're using a program that cannot be easily shutdown, or you might be in the middle of a complex editing a session, and you need access to a shell prompt to run a few other programs. A stopped process is called a "job". To pause of "stop" a process, use > "ctrl-z" fg will resume the most recently stopped program fg stands for "fore-ground" .. brins prgm back to the foreground. It's possible to pause ("stop") several programs at once. Can pause a program, start a second, pause that, and start a third, etc. Can selectively resume commands by usng the 'jobs' command to list all currently stopped jobs. These jobs will be preceded by a number, such as 1, 2 or 3 Can use fg with this number to selectively restart stopped programs e.g. "fg 4" will resume the 4th stopped process in the list provided by 'jobs' Programs running asynchronously (in the background) cannot be paused/stopped. (But they shouldn't need to be paused, cuz they don't prevent you from getting a shell prompt) |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 26th, 2009 at 6:08pm
07-05 - More Process Control (nice & nohup)
Each process is assigned a priority More important programs receive a large part of processing time, so they run faster Less important programs run more slowly. nice = program used to adjust a program's priority (make it more or less important) Running a program with a higher priority (faster) will cause other programs to run slower. Highest priority = -20 (strange, cuz it's a negative number) Lowest priority = 19 (note how highest number = lowest priority) Defult priority = 10 Mot programs use the default syntax > "nice -priority command [arguments]" e.g. "nice --20 find / -name output.txt" or "nice -20 backup /home" don't let the double -- confuse you. some user will not have permission to run negative number, which represent the highest priorities root superuser has all power to do anything nohup = no hangup nohup used to prevent programs from terminating when you log out. if program is started with nohup command, it won't terminate upon log-out. syntax = "nohup command [arguments] & e.g. "nohup backup /home &" any standard output goes (by default) to a file named nohup.out can be redirected elsewhere |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 26th, 2009 at 7:52pm Rad.in.UbuntuVM wrote on Jul 26th, 2009 at 4:44pm:
I've always heard it called "suspending" a process. If someone told me to stop a process, I'd kill (end) it. Rad.in.UbuntuVM wrote on Jul 26th, 2009 at 4:44pm:
Programs detached from the shell (or 'daemonized') cannot be suspended because they aren't controlled by the shell. Programs running in the background can easily be suspended by bringing them to the foreground (fg) and then suspending them. Rad.in.UbuntuVM wrote on Jul 26th, 2009 at 6:08pm:
Note that the nice level is an indication of priority. The distinction is important because process with a nice level of 19 (lowest priority) won't run much slower than a process with a nice level of 0 *unless* the processor is 100% utilized. Then, the higher priority process gets a larger share of processing time and the lower priority one slows down. Rad.in.UbuntuVM wrote on Jul 26th, 2009 at 6:08pm:
I'm not sure what Unix flavor this is referring to. The default priority on Linux is 0. Rad.in.UbuntuVM wrote on Jul 26th, 2009 at 6:08pm:
Your example is syntacticly correct, but it would not be good practice to run things like find and backup with such a high priority. There are important system processes that run somewhere around level -10. Starving these system processes of cpu time could cause the system to become unstable. In fact, I would lower the priority of find to something like +10. That way, it wouldn't interfere with anything important (and probably wouldn't run noticeably slower anyway.) In practice, you usually just use the default unless you have a reason not to. One good time I nice a process is when I'm transcoding audio or video. I set it to a nice 19 (lowest priority.) That way, I can still use my computer normally and the transcoding just uses any cpu time that I don't need. I barely notice it is running. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 26th, 2009 at 10:07pm
Appreciate your comments.
Doubt I'll need all these commands, but learning the shell ropes will give (is giving) me confidence. I'm ~ 2/3rds thru with this course. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 26th, 2009 at 11:53pm Rad wrote on Jul 26th, 2009 at 10:07pm:
Some of this is above what you need for just keeping your site up to date, but you are building a very solid foundation for getting comfortable in Linux. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 27th, 2009 at 1:30pm MrMagoo wrote on Jul 26th, 2009 at 11:53pm:
I agree. At least, I'm getting a feel for syntax and learning what can be done (especially how different programs can be connected together via | and '-exec') and this means I'll have a decent idea what questions to ask (.. if I find I need to know more). Knowing what you DON'T know is far better than NOT knowing (at all). I already feel far more comfortable at/with the command line. While looking for other stuff, I came across this link (titled "15 Essential UNIX commands"): http://www.petefreitag.com/item/426.cfm Seems a good starting point (for n00bies), no? |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 27th, 2009 at 2:28pm
07-06 - Scheduling Commands
Normally specified to run within the next 24 hours, but can schedule to run on any given day. at = command used to schedule programs to run in the future as in .. "at the following time, run the following commands." syntax -> "at 2245" you are then presented with an ">" prompt where you type all the commands you want to run. e.g. > cd /home/rad/temp (don't assume you'll be in any particular directory) > tar cf tempfiles.tar * > rm -rf * > "ctrl-d" when done (ctrl-d = "I'm done typing") Takes you back to a command prompt $ If any commands produce standard output, they are emailed to you. note "at" takes standard input so it's possible to get standard input from a FILE can put all commands in a file say, for example, the file is named "commands.txt" "at 2245 < commands.txt" at will give you a job number and tell you the date/time when commands will be executed. because the file "commands.txt" contains shell commands, it can be considered a shell script to make the file a shell scripy, need to make it executable (using chmod) e.g. "chmod u+x commands.txt" or "chmod 700 commands.txt" or even "chmod 100 commands.txt" Can now run the file as a program/script e.g. "commands.txt" Easy to create a shell script, but they can quickly get complicated (so complicated that shell scripting requires an entire training course) cron is another program used in scheduling jobs "at" only runs your job once you've reached ("at") the specified date/time. cron can run jobs on repeating schedules (but doesn't have an easy way to run it only once.) cron gets used far more often then at. Next module > vi text editor |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 27th, 2009 at 3:06pm Rad wrote on Jul 27th, 2009 at 1:30pm:
That's a good list. I don't think it's enough to be productive, tho. We'll have to combine it with other lists. By the way, I know you've posted it in other threads, but maybe you could post a link to the tutorials you are going through so that people who find your notes useful can check out the full course. Rad wrote on Jul 27th, 2009 at 2:28pm:
Another job scheduling system you should get familiar with is cron. at only runs your job once at the specified date/time. Cron can run jobs on repeating schedules (but doesn't have an easy way to run it only once.) Cron gets used far more often then at. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 27th, 2009 at 4:32pm
08-01 - vi - unix text editor
vi = short for "visual editor" a "funny old program" notoriously difficult to learn. learning vi can be a painful experience. vi is user-UNfriendly (NOT intuitive) emacs is the only real UNIX alternative vi is extremely powerful and feature-rich vi is one of the most feature-rich programs in the world (on any platform), .. especially for programming-related activities (editing .c files or shell scripts) can take quite some time to learn vi but once you become fluent with vi, you'll be able to perform even complex text-editing tasks faster than with any other program took the author a month to become comfortable with vi and another 3 or 4 to become an expert. vi is not a word processor vi = no formatting, such as bold or italics. Just text Another text editor > Notepad (very simple program) but vi is NOT simple (like Notepad) this is why an entire module is dedicated to vi vi = full screen program some text-editing program are "line-by-line" editors (vi is NOT one of them) vi evolved from line-based text-editing programs ed and ex. therefore vi shares many editing commands as ed and ex examples of types of files you can edit with vi > html, shell scripts, config files, source code like .c or .cpp why is vi so difficult to learn? vi was designed for terminals (keyboards) that did NOT contain a mouse or special keys, such as alt, arrow keys, page-up, page-down, left, right, function keys, home, end, etc. only key-strokes available - control keys .. only 20 or 30 or 40 control keys. vi is split into 2 modes. keystrokes have a different meaning in each mode. 1. command mode - each key (such as letter 't' or letter 'm') represent a specific editing command, tells vi to DO something, such as move around. 2. insert mode - normal text-editing mode, where key-strokes represennt text you want to INSERT into the document. eacape key - takes you into command mode (from insert mode) Normal to bounce back-n-forth between the two modes (command + insert) the letters "a, i, o,s c" take you back into insert mode. Easy to get confused over which mode you are in. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 27th, 2009 at 4:40pm MrMagoo wrote on Jul 27th, 2009 at 3:06pm:
cron is not chron? as is 'chronological? MrMagoo wrote on Jul 27th, 2009 at 3:06pm:
http://www.vtc.com/products/Unix-Shell-Fundamentals-tutorials.htm |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 27th, 2009 at 5:22pm
What are the major diffs between vi & vim?
Am I wasting my time learning vi? When I should be learning vim? This guy is actually running vim (v5.4), but he is not going to be reviewing any of the 'improved' features. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 27th, 2009 at 6:30pm Rad wrote on Jul 27th, 2009 at 4:32pm:
I don't find it hard to know which mode I'm in. Vim often puts a "Insert" flag at the bottom left of the screen to let you know you are in insert mode. Also, you'll know as soon as you press any key what mode you are in since the behavior is completely obviously different between modes. What can be confusing is when it switches modes when you aren't expecting it. For example, backspace and delete both cause you to exit insert mode in Vi. Arrow keys also don't work as expected in Vi. Rad wrote on Jul 27th, 2009 at 5:22pm:
Vim can color code your text to help show syntax if it knows what kind of text it is. For example, a file named something.c will have textual highlighting to help highlight C syntax. Many types of text files are supported this way, including html. Vim also acts more intuitively on keys that didn't exist on the keyboard when Vi was invented. The arrow keys, for example, work as expected in Vim but cause nothing but frustration in Vi while in insert mode. Rad wrote on Jul 27th, 2009 at 5:22pm:
Not at all. The things you learn translate directly. Rad wrote on Jul 27th, 2009 at 4:40pm:
It is short for chronograph, but the service is called cron or crontab. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 27th, 2009 at 7:35pm
08-02 - Manipulating files with vi (start vi, edit files, save & quit)
Starting vi Can open/start vi with either an existing document or with an empty canvass To edit a file -> "vi filename(s)" e.g. "vi config.txt" or "vi *.txt" Running "vi" with no argument will open a new/blank page. When opening multiple files, ":n" takes you to the next file. tildes ("~") down left sides = indicate no text there. Entering text Once vi starts, you'll automatically be in command mode Hit (for example) the 'a' key to enter insert mode and append text after cursor. Press ESC to return to command mode Saving changes & exiting vi ":w" (w for writing the file) - only works if a filename has been specified trying to ":w" with no filename will generate error > "No file name" In order to "Save As", need to enter ":w filename" when saving, vi will report the number of lines and characters saved. ":q" to quit, only if no changes made, or changes have already been saved ":q" returns you to a shell prompt If you try to ":q" without first saving changes > get error message > "No write since last change (use ! to override)" This error message is useful .. prevents you from accidentily exiting vi without saving changes. ":wq" saves the file & then quits vi ":wq" is probably the most common way to exit vi ":x" or "ZZ" (notice capital letters Z, with no preceding colon ) = saves the file IF you've made changes. If no changes made, simply quits. BUT this can be a problem if you've ACCIDENTALLY made changes (especially if you're not familiar with vi). So the file may be modified without your knowledge. ":q!" = abandon any changes and really quit! ":w!" = write to read-only file (you must own the file) ":e filename" =open another file (e = edit) can only use :e if you haven't made any unsaved changes to current file NOTE > can only edit one file at a time in vi. Can't have 2 files open, boths contaning edits and requiring saves. ":e! filename" will abandon any changes to current file before opening new file. ":e#" or ctrl-6 to return to previous file. (makes it easy to bounce back and forth between 2 files) ":n" moves on to the next file if you open vi with more than one file in the command line. If you enter :n at last file, will get an error saying "Cannot go beyond last file" Except for previous file (":e#") Cannot go backwards thru list. Can only go forwards. If you want to return to an earlier file (other than previous file), have to do ":rew" (rewind) to return to first file, and then :n as necessary. ":f" or ctrl-g displays details about current file you're in. (i.e. filename, line number etc.) Wow. I think this was the longest one so far. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 28th, 2009 at 4:59am Rad wrote on Jul 27th, 2009 at 7:35pm:
This is another improvement that was made in Vim. http://www.cs.swarthmore.edu/help/vim/windows.html Allows you to have multiple files open and work on both. |
Title: Re: Using the Unix/Linux shell command-line Post by Spanky on Jul 28th, 2009 at 11:29am
What exactly does the shell interact with? Is the the "UNIX operating system"? The kernel? What is the correct terminology?
Do you happen to know HOW MANY Unix utility programs there are? Or where I might find out? |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 28th, 2009 at 1:35pm
http://www.vim.org/download.php
I noticed on the Vim download page it says: Quote:
Compiling sources. Is this something you actually do? Frequently? Rarely? Ever? It says it's not difficult. Don't think I've compiled anything since CS-1A in college. (Pascal.) |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 28th, 2009 at 1:55pm
If I try to launch "vim" in the Rad VPS (CentOS 5.x), I get error "command not found".
If I try to launch "vi" in Rad VPS, Vim 7.0 comes up (not vi) If I try to launch either vi or vim in Ubuntu 9.04, Vim 7.2 comes up (for both commands). Recall I/we installed Vim in Ubuntu via command line. Quote:
So it seems Ubuntu has no vi. Are you sure it comes with vi? |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 28th, 2009 at 2:54pm
From Wiredtree sppt:
Quote:
Quote:
Just checked my version of Vim in Rad VPS. Still says "v7.0 Seems no way of telling whether minimal vs common. I would've expected to get Vim 7.2 if upgraded to latest version. http://www.vim.org/download.php I ran this today: rpm -qa | grep vim .. which is pretty cool for me, since I actually have a decent idea what it does/means. But it returned BOTH minimal and common. Quote:
|
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 28th, 2009 at 5:01pm Rad.in.UbuntuVM wrote on Jul 28th, 2009 at 1:55pm:
I was checking that out last night myself. It seems this behavior change with 9.04. Before that, they would install Vi and not Vim. Seems it now comes with Vim, which is a good thing. Most other distros have been shipping with Vim as long as I've been in Linux. Even Ubuntu used to back around 4.10. Something changed right around 4.10 and they started shipping with Vi, which caused me all manner of confusion since I didn't know the difference at the time (except that the new version didn't act like I expected.) I'm glad to see they've changed back. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 28th, 2009 at 5:20pm
08-03 - Moving Around (without making changes to the document)
Vim is an "improved" version of vi. The arrow keys, for example, work as expected in Vim. All following commands apply only to command mode (not insert mode) Moving around within a line: Spacebar or l key > moves ahead 1 character/space. Can also try right-arrow key. (May or may not work) Backspace or h > moves back 1 character/sapce. Can also try left-arrow key. For both these commands, you can type a number, to move either back or fwd by a certain number of characters. $ takes you tolast character on line. ^ or 0 (zero) takes to you to first character on line. fX (X =any character) = moves to the next instance of that character. f = find e.g. "f," takes you to next comma. ; (semi-colon) = takes you to next instance of character X previously mentioned. Moving between lines. Enter key or j or + key = moves down to next line. (Can also try down-arrow key.) k or - (minus) key = moves up 1 line (Can also try up-arrow.) It's possible to type a number before these commands to move (up or down) by that number of lines. Notice how h, j, k & l are all together on keyboard (move-left, move-down, move-up, move-right) Note terminology > "^" = CTRL key ^f = move forward 1 page (like page down) ^b = move back 1 page (like page up) ^d = move down half a page ^u = move up half a page G (capital letter G) = Go to last line. 1G = Go to first line. nG (where n = any number) = Go to that line number e.g. "25G" = Go to line 25. Other commands to move around /pattern = how to FIND text in document. This takes to to the first instance AFTER where your cursor is currently located. (Not the first instance in the file.) e.g. "/gnarly" takes you to first instance of 'gnarly' AFTER where cursor was located. Vim will also highlight all instances of the word searched for. After entering search-query, can use: n = to move to the next occurence, or N (capitl N) to move to previous occurence When you get to the last instance (bottom of page), it will wrap around and restart at the top/beginning w = goes forward 1 word b = goes back 1 word Can enter a number preceding these commands to make vi go fwd/back by that number of words. % = find matching bracket .. i.e. (), [].{} = useful feature not found in many other text editors. Cursor must be resting on a bracket. This feature does NOT include angle brackets <> mx = mark a line with a label (x = label can be a-thru-z, so 26 possible labels). Think of these as bookmarks. Choose a letter that corresponds to the thing you're marking. e.g. Maybe mark beginning of Index with "mi" (i for index) Only valid for current vi sessions. Cleared when you quit vi. 'x = (single-quote x) = Jump to a particular bookmark e.g. 'i = takes you to bookmark labeled i '' = returns you to the last place that you jumped FROM (doesn't have to be marked) |
Title: Re: Using the Unix/Linux shell command-line Post by Rad.in.UbuntuVM on Jul 28th, 2009 at 5:36pm
This is ~ 3/4ths the way thru. The remaining modules are:
08-04 - Basic editing [ No 08-05 module ] 08-06 - Configuring vi 09-01 - The Unix File System 09-02 - How Files are Stored 09-03 - Understanding Links 09-04 - Linking Files 09-05 - Symbolic Links 09-06 - Unix File Types 10-01 - Communication 10-02 - Using mail 11-01 - Customizing the Shell environment 11-02 - Environmental Variables 11-03 - Your path 11-04 - Your prompt 11-05 - .profile 11-06 - Command-line editing 11-07 - Other Shell Customizations & Options 11-08 - The end. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 28th, 2009 at 6:46pm Spanky wrote on Jul 28th, 2009 at 11:29am:
It interacts with the kernel. The operating system is the combination of the kernel, shell, GUI (if installed) and all the system utilities. Spanky wrote on Jul 28th, 2009 at 11:29am:
I don't know how many there are and I doubt anyone does. Easily thousands. If you are talking about Unix proper, then it depends on the type of Unix. HP Unix doesn't work the same as AIX (made by IBM) or Solaris (made by Sun). If you are talking about the BSD families (Unix descendants) and Linux (written from scratch to be compatible with Unix) then most of the utilities come from the GNU project. http://www.gnu.org/ GNU actually has a kernel that they have been working on for ~20 years, but it isn't done yet, so it is usually paired with the Linux kernel. Rad.in.UbuntuVM wrote on Jul 28th, 2009 at 1:35pm:
Yes, I do it regularly (although not frequently.) Sometimes the program you want is not available in a package for your particular distribution, or the version in the repositories is not current and you want some new feature. A good example of this is BOINC: http://boinc.berkeley.edu/ The version in the Ubuntu repository is 6.2.x. Versions before 6.6.0 don't support using your graphics card to do computations. So, if you want to put your idle nVidia graphics card to use doing volunteer computing in Linux, you have to install the BOINC client from source. So, we get the source and compile it. It isn't hard at all. For many programs, you simply untar the source, cd into the directory, and run 'make'. Then, su to root and run 'make install'. Done. Sometimes you have to edit the make file to enable certain options or change where it installs to, but usually the defaults work fine. |
Title: Re: Using the Unix/Linux shell command-line Post by MrMagoo on Jul 28th, 2009 at 6:50pm Rad.in.UbuntuVM wrote on Jul 28th, 2009 at 2:54pm:
He didn't upgrade you. He installed some optional packages to give your current version more features. |
Title: Re: Using the Unix/Linux shell command-line Post by Rad on Jul 30th, 2009 at 9:24pm
This thread continues here:
http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1248820932 Using the Unix/Linux Shell Command-line - _Part 2 |
Radified Community Forums » Powered by YaBB 2.4! YaBB © 2000-2009. All Rights Reserved. |