OK, figured out my prob. I was using invalid flags which work just spiffy on linux but not on mac. So the invalid flags would stop the command from running properly instead of being skipped over.
Now that my aliases (eg: alias lsl="ls -sCFGHTh") are working spiff-tastically, I've noticed something: OSX.3 DP finally has color ls (ls -G) working, by default. No extra stuff to install! Yay!!
On the one hand, I'd love to but there's about 10,000 relevant search results to be gotten from google with search terms like 'os x terminal/bash/scripting/shell/etc).
Terms rule in ways that are impossible to describe... you have to see for yourself the awesome cool stuff you can do.
Like remotely copy files and log into machines half-way around the world. Like 'pausing' apps (ie: a cpu-hogging one) w/out quitting them, then restarting them again at any point.
Another good example: I was searching for a file using OSX.3's new finder, which is prone to crashing when searching. Whole system froze. Not Command-Option-Escape, nothing. Fuxxored, right? Wrong. I had SSHD (a secure way to remotely log in) enabled on my Tibook, just for such an occasion. So I go to my other Powerbook, a Wallstreet running linux, and did:
ssh -l root 192.168.xxx.xxx (my Tibook's address)
killall Finder
exit
problem solved! Finder restarts, everything is just spiffy-keen.
To enable sshd (which must be running to ssh into that computer), Sys Prefs -> Sharing -> Services -> remote login
open a Terminal.app and:
ssh 127.0.0.1
(127.0.0.1 means 'this computer' as opposed to any other on the net)
you are logged in to your computer via ssh.
Or, let's pretend that iTunes is a CPU hogging pig-dog (snort! Oink! Arf, Arf!!). Which it is. But pretend iTunes is ANY cpu hogging app, say a 3d renderer, and you want to play Ghost Recon w/ out quitting your 3d render and having to restart it from scratch.
Open Term, and type (or copy paste):
/Applications/iTunes.app/Contents/MacOS/iTunes
and play some music.
now, to 'pause', type Control-z
paused! Now type:
fg
Unpaused! fg 'foregrounds' the app, bg 'backgrounds' the app (so you can still type/execute more commands.
If you have multiple apps paused, %1 unpauses the first paused process, %2 the second, etc.
That way, you can pause it, fire up GR, frag some people, quit GR, unpause your render and it picks up exactly where it left off.
The actual term for this is zombification, or zombie processes.
This is a Mac forum? A lot has changed, hasn't it?
Could someone explain some of this to a beginner who can putter around in a terminal but doesn't know about the individual shells?
yea, me and others have spent the last 2 years embracing macosx's *nixy underpinnings. some already had experience running other *nixes. and to think i used to fear and hate the cli.
if you really want to get good at the terminal, i would recommend reading man pages (if anyone says, "rtfm" thats what they are asking you to do in unkind terms). man pages are created by the people who write the various command line programs to explain the details and use of those programs. if you dont know how to work a program, like 'ls' for instance, you can type 'man ls' in a terminal window, and a 'man page' will show up explaining all the bitty details about it. you can move down through the 'pages' with 'space', or one line at a time with <enter> or <return>. after you are familiar with basics of moving maneuvering through man pages, you might be interested in reading the man page for more ('mac more'). that is the 'pager' that is used by default. when you type 'man <something>' the 'man' program throws its output at 'more' so that the 'pages' will fit on the screen. you might also want to read 'man less', as less is a better, imo, pager. to use less as a pager, type "setenv PAGER 'less'". next time you use man, 'less' will be your pager instead of 'more'. (i should also note, that to quit less, you type 'q')
another important tidbit is shells. when you are in the terminal program, each window runs a program called a 'shell'. on macosx, the default 'shell' is 'tcsh' (as this topic pointed out earlier). to learn more about the shell and its particulars, you can type 'man tcsh'. i'll try to explain some of the nitty bits for you. every command you type is passed to the shell and the shell then decides what to do with it (like run other programs, or execute internal functions). shells also deal with some other things, like if you want to type a command, but it is long, you can usually type part of it then hit <tab>. most shells will try to fill out the rest of the command for you. some shells will also give you a list of commands that are spelled similarly. shells also decide what the prompt looks like (the prompt being all the text that appears on a line before you type in a command). depending on what shell you use, you can also setup a list of commands to execute everytime you open a new shell (often called your profile, because in the 'bash' shell, that is the name of the file that holds the commands). these commands typically fill up some common 'alias'es and setup your environment. alias is a command that allows you to create short versions of a command. like if you have an alias like 'myls' that is equal to 'ls --color', everytime you type 'myls' the shell will interpret that as 'ls --color'. to create an alias with tcsh, type 'alias <name> <command>' (putting multi-word commands in quotes, like 'alias myls "ls --color"'). the tcsh shell uses the '.tcshrc' as its 'profile'. so if you find some commands you like to execute every time you open a shell (like "setenv PAGER less"), you may want to put them into a file (one per line, and/or separated by semicolons), and name that file ".tcshrc" (and put it in your home directory). you may already have a .tcshrc, in which case you can simply add your new commands to the end of it. next time you open 'tsch' those commands will be executed.
another thing to note is the environment. this is a (sometimes large) map of keys (sometimes called variables) and values. you can see your environment (in tcsh) with 'setenv | less' (note: less will page through incase you have several pages of commands). these keys and values are very important to any *nix (and other posix compliant) operating system. many programs will run differently depending on what variables you have in the environment, and what values are assigned to them. 'man' as an example, will use a different pager depending on the value of the 'PAGER' variable. and if this variable is not in the environment, man defaults to using 'more' as a pager.
theres so much more for you to learn, like piping, but i've already gotten longwinded.
Thank you very much. I haven't been using OS X, since all I have to use is my father's OS 9 computer and my own Linux machine. I think this will help me get a bit more out of the system. And I wonder what sort of wacky interface hybrids one could come up with, taking the strong points of the GUI and pervasively integrating them with a CLI.
This stuff is ÜBER-handy on linux. On my linux install, these days, all I have are aterm, mozilla, fluxbox, and my arsenal of CLI apps (w3m, screen, mp3blaster, alsamixer, bash scripts I write, etc). There's napster clients, instant messengers, distributed compilers, mp3 encoders, CD burners...
OK, figured out my prob. I was using invalid flags which work just spiffy on linux but not on mac. So the invalid flags would stop the command from running properly instead of being skipped over.
Now that my aliases (eg: alias lsl="ls -sCFGHTh") are working spiff-tastically, I've noticed something: OSX.3 DP finally has color ls (ls -G) working, by default. No extra stuff to install! Yay!!
hmm, so you're saying that jagwyre's ls doesn't have --color ?
btw, here's my bash, since I just started working with osx at home, so this is copy/pasted from my debian box, I'd be happy if the colouring could work in osx's bash :
hmm, so you're saying that jagwyre's ls doesn't have --color ?
btw, here's my bash, since I just started working with osx at home, so this is copy/pasted from my debian box, I'd be happy if the colouring could work in osx's bash
you can download and install fileutils (maybe its coreutils) from the fsf. you could also get fink and install the color-enabled ls from there. i never even considered putting a prompt on two lines; thats a cool idea, johan.
Expand it, and sudo mv it to /usr/local/bin/ls. If you want to see help for it, just type 'ls --help'. And, if you ever want the stock ls back, just type /bin/ls, and you got your regular ls back. To call it with color, just use a --color tag.
Oh, and here's my .bashrc. Some of the functions really ought to be commands in and of themselves (the kick functionality, especially), and I'm still kicking around a lot of this stuff. For example, the ip function... there has got to be a better way to do this, eh?
I have this in my .bash_profile, to simplify my life:
Code:
PATH=/usr/local/bin:$PATH
. /sw/bin/init.sh #Use the Fink helper to set my paths.
# use .bashrc if it exists
if [ -f ~/.bashrc ]; then
. ~/.bashrc #this way it always reads from .bashrc whether or not it's a login shell
fi
Here's .bashrc:
Code:
# use the OS X file structure setup
if [ -f ~/Library/init/bash/aliases.mine ]; then
. ~/Library/init/bash/aliases.mine
fi
if [ -f ~/Library/init/bash/rc.mine ]; then
. ~/Library/init/bash/rc.mine
fi
This allows me to separate my stuff from general bash settings.
Oh, and one quick question: In TCSH, I could set an environment variable that allowed me to do case-insensitive tab-completion. Is there a variable like that in bash?
It pops up in all sorts of places, and there's no man page for stuff like that.
Any ideas?
Quite honestly, I have too. It really doesn't seem to make much sense to me.
Here's what I've been able to grok together... please excuse any inaccurate comments, and correct me on it. I'm still learning.:
Edit: WARNING: You are embarking on a long post. It should be helpful, and I don't think you should get lost, but it will take a bit. Consider yourself WARNED
It has to do with the output of commands. I'm sure you've got that far, too, but I want everyone on board.
A command outputs different things with a 'descriptor' number that says what kind of a message it is. So, 1 is typically regular output, also called stdout. However, if a message outputs an error, it gives output with the descriptor 2, also called stderr. Then there are another 125 numbers that I think just are used for different types of errors. I haven't run into any descriptor that is greater than 2.
Ok, so now the '>' character is for redirection. You take something from the left side, and put it into the right side. Simple enough, right? So, from what I can tell, the 2>&1 takes output with a descriptor of 2, and adds it into output with descriptor 1. Clear as mud I'm sure.... nothing like a good example to clear things up.
We'll do a simple variable assignment. The syntax is really easy, you just do something like this:
Code:
$ var=123
Almost every place you use this variable after the initial assignment it must be preceded with a $ sign (Don't confuse this with the $ I put in the code.... that's just to signify that it's a command line... and since we are in a "bash tcsh" topic-pun intended, I can't simply use a % ). So, to see what a certain variable contains, the best way is to:
Code:
$ echo $var
You should get on the next line the contents of the variable, instead of $var. Everybody still with me? One more thing before we get into output. A way you assign a variable to the output of a certain command is with `backticks` (the key below escape and above tab). So, here's an example:
Code:
$ test=`echo "Hello, this is a test"`
$ echo $test
Hello, this is a test
To retain the whitespace formatting of a variable, put it in double quotes, like this:
Code:
$ network=`netstat -p tcp`
$ echo "$network"
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 localhost.1033 localhost.952 ESTABLISHED
tcp4 0 0 localhost.952 localhost.1033 ESTABLISHED
tcp4 0 0 localhost.ipp *.* LISTEN
tcp4 0 0 localhost.1033 localhost.1020 ESTABLISHED
tcp4 0 0 localhost.1020 localhost.1033 ESTABLISHED
tcp4 0 0 localhost.1033 *.* LISTEN
That should be enough variable preface to get through my example. Oh, and I'll use the command 'cat', which simply displays the contents of a text file.
Here's a command that outputs an error:
Code:
$ cat wrongfilename
cat: wrongfilename: No such file or directory
It gives an error as output which makes sense, because there isn't a file named wrongfilename, and it's trying to read from it.
OK. Simple enough. Let's throw a wrench into things. Lets take the command above (which gives an error), and send it's output into a variable
Code:
$ data=cat wrongfilename
cat: wrongfilename: No such file or directory
$ echo $data
$
Uh, oh. We still see the error on the terminal. When we assigned a variable to output from an echo command, nothing showed up. Look at what is in the variable data. Nothing?!? That's odd.
The answer is that variables are only assigned to the standard output (1) of a command. So, what is happening is that cat is returning an error (output of type 2), and instead of getting put into the variable "$data", it gets returned to the terminal screen. Since it's not sending anything out as type 1, nothing gets put into the variable, and it is still null (echo puts a newline on everything, even a null).
So, we need to make the cat command change it's error from type two to type 1, so it goes into the variable correctly. The way we do that is with the redirection character. I haven't perfected the syntax on this one... I've just stolen it from examples I've seen elsewhere. So, let's do this:
Code:
$ data=`cat wrongfilename 2>&1`
Aha! OK, so nothing got returned to the terminal screen, like it did last time. That's a good sign. Now try
Code:
$ echo $data
cat: wrongfilename: No such file or directory
Yay! Now we have the output from the cat command going into the variable, since we redirected the output in type 2 to type 1, and that's what the variable picks up.
Now, for a trickier example. The traceroute command shows all the internet gateways a message goes through to get to the destination. We'll do something easy like this:
Code:
$ traceroute 127.0.0.1
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
1 localhost (127.0.0.1) 0.497 ms 0.175 ms 0.076 ms
127.0.0.1 is called the loopback address. It simply is an alias for the ip address of the computer that you are on. So, congrats. You've found your own computer Just to get a feel for the command, try something like 'traceroute www.yahoo.com'
Back to the point, try setting a variable to the output of this command. You get something like this:
Code:
$ data=`traceroute 127.0.0.1`
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
$ echo $data
1 localhost (127.0.0.1) 0.521 ms 0.153 ms 0.065 ms
WHAT!?! What's happening? OK, so, obviously, the creators of the traceroute command thought that it was a good idea to only have the substance of the route trace as standard output (1). Makes sense, I suppose. But then you have this strange side effect of getting what looks like an error message when you assign a variable.
So, if you play around with things a little bit, try this:
Code:
$ data=`traceroute 127.0.0.1 2>&1`
$ echo "$data"
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
1 localhost (127.0.0.1) 0.508 ms 0.158 ms 0.07 ms
Ahh, good. That's what we're looking for. So, what was happening was the header was being put out as an error message, and the terminal screen was picking it up, but the variable wasn't.
Lets try some more stuff out. What if I try to overwrite the output of type 1 with the output of type two, instead of tacking on to it? I assume the & character makes the command keep the original output of type 1, and just reassign type 2 output to type 1. Let's try doing a simple 2>1:
Code:
$ data=`traceroute 127.0.0.1 2>1`
bash: 1: Permission denied
Hmm. That's odd. OK, well I've looked around on this before, and I've seen this syntax used:
Code:
$ data=`traceroute 127.0.0.1 2>&1 1>&-`
$ echo $data
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
The structure itself makes sense, but it seems out of order to me. Ok, so the 1>&- obviously means that we are getting rid of the output with type 1. But didn't we just reassign the output from 2 to 1? Shouldn't that have gotten clobbered, too? This is where I lose myself, and I don't know where to go from here. If we try it in the order I think it should go in, it looks like this:
Code:
$ data=`traceroute 127.0.0.1 1>&- 2>&1`
bash: 2: Bad file descriptor
WHA? I've also thought that it might be a good idea to take all the types of output and redirect them into type 1. like this:
Code:
$ data=`traceroute 127.0.0.1 *>&1`
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
$ echo $data
1 localhost (127.0.0.1) 0.504 ms 0.152 ms 0.072 ms
Curse you for making me read the description of redirection in the bash man page. This is pretty arcane stuff. On the other hand, I understand it much better now.
It's all in the man page, if not especially clear (<- major understatement.) I won't even try to rehash all of what's written there, just a few salient points.
1) The ">&" operator is for duplicating file descriptors. So "2>&1" says to make stderr a duplicate of stdout, so stderr will go to the same place as stdout, in effect merging the two.
2) As for the order of the redirections, I've stared at this for a bit and justify it as follows:
Code:
$ cat file 2>&1 1>&-
The reason this is correct is that first, stderr is created as a duplicate of stdout. That is correct. Then, stdout is "closed". The important thing is that descriptor #2, stderr, is a copy of stdout, as opposed to a pointer to stdout, so subsequently closing stdout doesn't affect stderr.
Whereas, this code:
Code:
$ cat file 1>&- 2>&1
first closes stdout, then attempts to make stderr a copy of stdout, which it can't do because stdout is gone, so it reports the error. From the man page:
Quote:
If the digits in word do not specify a file descriptor open for output, a redirection error occurs.
("word" refers to the expression after ">&") So that is why the error is reported.
Similarly, the first example in the man page actually makes sense to me now:
Quote:
Note that the order of redirections is significant. For example, the command
Code:
ls > dirlist 2>&1
directs both standard output and standard error to the file dirlist, while the command
Code:
ls 2>&1 > dirlist
directs only the standard output to file dirlist, because the standard error was duplicated as standard output before the standard output was redirected to dirlist.
Again, the key here is that the >& operator makes a separate copy of the descriptor. In the first example, stdout is redirected to dirlist, and then stderr is copied from the redirected stdout. In the second example, stderr is copied from the original stdout, then stdout is redirected, not affecting the copy.
I don't know if that makes sense to anyone else, but I'm satisfied.
3) This example you tried:
Code:
$ data=`traceroute 127.0.0.1 2>1`
bash: 1: Permission denied
tries to redirect stderr to a file named "1". Perhaps you didn't have write permission in that directory, or there was already a protected file named "1". Otherwise it should work, though not the way you intended. The standard redirection operator ">" assumes the expression on its right is a filename; to do what we're doing here you want to copy descriptors, as described previously.
4) I don't know about the "*>&1" notation; I can't see in the man page that wildcards are allowed as file descriptors. That doesn't mean it doesn't exist, just that I can't find it, and haven't seen it before...
Well thanks, guys. I've been wondering for ages. No one could answer that for me. I also always wondered where the heck to look for a man page; obviously, 'man >' doesn't work, nor 'man redirection'.
Comments
Now that my aliases (eg: alias lsl="ls -sCFGHTh") are working spiff-tastically, I've noticed something: OSX.3 DP finally has color ls (ls -G) working, by default. No extra stuff to install! Yay!!
Could someone explain some of this to a beginner who can putter around in a terminal but doesn't know about the individual shells?
Terms rule in ways that are impossible to describe... you have to see for yourself the awesome cool stuff you can do.
Like remotely copy files and log into machines half-way around the world. Like 'pausing' apps (ie: a cpu-hogging one) w/out quitting them, then restarting them again at any point.
Another good example: I was searching for a file using OSX.3's new finder, which is prone to crashing when searching. Whole system froze. Not Command-Option-Escape, nothing. Fuxxored, right? Wrong. I had SSHD (a secure way to remotely log in) enabled on my Tibook, just for such an occasion. So I go to my other Powerbook, a Wallstreet running linux, and did:
ssh -l root 192.168.xxx.xxx (my Tibook's address)
killall Finder
exit
problem solved! Finder restarts, everything is just spiffy-keen.
To enable sshd (which must be running to ssh into that computer), Sys Prefs -> Sharing -> Services -> remote login
open a Terminal.app and:
ssh 127.0.0.1
(127.0.0.1 means 'this computer' as opposed to any other on the net)
you are logged in to your computer via ssh.
Or, let's pretend that iTunes is a CPU hogging pig-dog (snort! Oink! Arf, Arf!!). Which it is. But pretend iTunes is ANY cpu hogging app, say a 3d renderer, and you want to play Ghost Recon w/ out quitting your 3d render and having to restart it from scratch.
Open Term, and type (or copy paste):
/Applications/iTunes.app/Contents/MacOS/iTunes
and play some music.
now, to 'pause', type Control-z
paused! Now type:
fg
Unpaused! fg 'foregrounds' the app, bg 'backgrounds' the app (so you can still type/execute more commands.
If you have multiple apps paused, %1 unpauses the first paused process, %2 the second, etc.
That way, you can pause it, fire up GR, frag some people, quit GR, unpause your render and it picks up exactly where it left off.
The actual term for this is zombification, or zombie processes.
Originally posted by Mac The Fork
This is a Mac forum?
Could someone explain some of this to a beginner who can putter around in a terminal but doesn't know about the individual shells?
yea, me and others have spent the last 2 years embracing macosx's *nixy underpinnings. some already had experience running other *nixes. and to think i used to fear and hate the cli.
if you really want to get good at the terminal, i would recommend reading man pages (if anyone says, "rtfm" thats what they are asking you to do in unkind terms). man pages are created by the people who write the various command line programs to explain the details and use of those programs. if you dont know how to work a program, like 'ls' for instance, you can type 'man ls' in a terminal window, and a 'man page' will show up explaining all the bitty details about it. you can move down through the 'pages' with 'space', or one line at a time with <enter> or <return>. after you are familiar with basics of moving maneuvering through man pages, you might be interested in reading the man page for more ('mac more'). that is the 'pager' that is used by default. when you type 'man <something>' the 'man' program throws its output at 'more' so that the 'pages' will fit on the screen. you might also want to read 'man less', as less is a better, imo, pager. to use less as a pager, type "setenv PAGER 'less'". next time you use man, 'less' will be your pager instead of 'more'. (i should also note, that to quit less, you type 'q')
another important tidbit is shells. when you are in the terminal program, each window runs a program called a 'shell'. on macosx, the default 'shell' is 'tcsh' (as this topic pointed out earlier). to learn more about the shell and its particulars, you can type 'man tcsh'. i'll try to explain some of the nitty bits for you. every command you type is passed to the shell and the shell then decides what to do with it (like run other programs, or execute internal functions). shells also deal with some other things, like if you want to type a command, but it is long, you can usually type part of it then hit <tab>. most shells will try to fill out the rest of the command for you. some shells will also give you a list of commands that are spelled similarly. shells also decide what the prompt looks like (the prompt being all the text that appears on a line before you type in a command). depending on what shell you use, you can also setup a list of commands to execute everytime you open a new shell (often called your profile, because in the 'bash' shell, that is the name of the file that holds the commands). these commands typically fill up some common 'alias'es and setup your environment. alias is a command that allows you to create short versions of a command. like if you have an alias like 'myls' that is equal to 'ls --color', everytime you type 'myls' the shell will interpret that as 'ls --color'. to create an alias with tcsh, type 'alias <name> <command>' (putting multi-word commands in quotes, like 'alias myls "ls --color"'). the tcsh shell uses the '.tcshrc' as its 'profile'. so if you find some commands you like to execute every time you open a shell (like "setenv PAGER less"), you may want to put them into a file (one per line, and/or separated by semicolons), and name that file ".tcshrc" (and put it in your home directory). you may already have a .tcshrc, in which case you can simply add your new commands to the end of it. next time you open 'tsch' those commands will be executed.
another thing to note is the environment. this is a (sometimes large) map of keys (sometimes called variables) and values. you can see your environment (in tcsh) with 'setenv | less' (note: less will page through incase you have several pages of commands). these keys and values are very important to any *nix (and other posix compliant) operating system. many programs will run differently depending on what variables you have in the environment, and what values are assigned to them. 'man' as an example, will use a different pager depending on the value of the 'PAGER' variable. and if this variable is not in the environment, man defaults to using 'more' as a pager.
theres so much more for you to learn, like piping, but i've already gotten longwinded.
Originally posted by 1337_5L4Xx0R
OK, figured out my prob. I was using invalid flags which work just spiffy on linux but not on mac. So the invalid flags would stop the command from running properly instead of being skipped over.
Now that my aliases (eg: alias lsl="ls -sCFGHTh") are working spiff-tastically, I've noticed something: OSX.3 DP finally has color ls (ls -G) working, by default. No extra stuff to install! Yay!!
hmm, so you're saying that jagwyre's ls doesn't have --color ?
btw, here's my bash, since I just started working with osx at home, so this is copy/pasted from my debian box, I'd be happy if the colouring could work in osx's bash :
alias ls='ls -AF --color=auto'
alias ll='ls -asl --color=auto'
#alias mc='mc -c'
# some more ls aliases
#alias ll='ls -asl'
#alias la='ls -A'
#alias l='ls -CF'
# set a fancy prompt
#PS1='\\u@\\h
export PS1='\
\\[\\033[32m\\]\\w\
\\[\\033[0m\\][\\[\\033[1;31m\\]\\u@\\h\\[\\033[1;34m\\]\\[\\033[0m\\]] \\[\\033[0m\\]'
Originally posted by johan
hmm, so you're saying that jagwyre's ls doesn't have --color ?
btw, here's my bash, since I just started working with osx at home, so this is copy/pasted from my debian box, I'd be happy if the colouring could work in osx's bash
you can download and install fileutils (maybe its coreutils) from the fsf. you could also get fink and install the color-enabled ls from there. i never even considered putting a prompt on two lines; thats a cool idea, johan.
hmm, so you're saying that jagwyre's ls doesn't have --color ?
Jag doesn't have a colour ls in bash (Panther does, which I'm using).
ls --color does not appear to be an option. ls -G is the way to color ls.
my .bashrc:
DISPLAY=":0.0"
EDITOR=pico
PAGER=less
PS1='\\u@\\h
alias nano="pico"
alias ls="ls -FG"
alias ll="ls -Alh"
alias lsl="ls -sCFGHTh"
alias df="df -h"
alias du="du -h --max-depth=1"
alias ps="ps -e"
alias wallstreet1_ssh="ssh -X [email protected]"
alias wallstreet2_ssh="ssh -X [email protected]"
alias top="top -o cpu"
Expand it, and sudo mv it to /usr/local/bin/ls. If you want to see help for it, just type 'ls --help'. And, if you ever want the stock ls back, just type /bin/ls, and you got your regular ls back. To call it with color, just use a --color tag.
I have this in my .bash_profile, to simplify my life:
PATH=/usr/local/bin:$PATH
. /sw/bin/init.sh #Use the Fink helper to set my paths.
# use .bashrc if it exists
if [ -f ~/.bashrc ]; then
. ~/.bashrc #this way it always reads from .bashrc whether or not it's a login shell
fi
Here's .bashrc:
# use the OS X file structure setup
if [ -f ~/Library/init/bash/aliases.mine ]; then
. ~/Library/init/bash/aliases.mine
fi
if [ -f ~/Library/init/bash/rc.mine ]; then
. ~/Library/init/bash/rc.mine
fi
This allows me to separate my stuff from general bash settings.
So, then in my aliases.mine file:
#My Aliases and Functions
# get to BASH customization directory
alias rc='cd ~/Library/init/bash/'
# ls aliases
alias ls='colorls --color'
alias ll='ls -l'
alias la='ls -A'
alias lla='ls -lA'
# No overwriting
alias mv='mv -i'
alias cp='cp -i'
# cd stuff
alias cd='pushd 1>&-'
alias up='cd ..'
alias dn='cd'
function acr ()
{
cd ../$1
}
alias ba='cd'
alias back='popd 1>&-'
alias home='cd ~'
# a nice reader
alias c='less -e'
# PS aliases
alias ps="ps -axco 'pid command user stat %cpu'"
alias rps="ps -axco 'pid command user stat %cpu' | less -e"
alias crps="ps -axrco 'pid command user stat %cpu' | less -e"
alias e='exit'
#-----------------FUNCTIONS------------------#
# kick a user from a certain port
function kick ()
{
sudo ipfw add deny tcp from $1 to any $2
}
# change ip from alpha to numeric output
function ip ()
{
out=`traceroute -m2 $1 2>&1 1>&- | grep "traceroute .*, 2 hops max, "`
out=`echo $out | sed "s/traceroute to .* (//" | \\
sed "s/), 2 hops max, 40 byte packets//"`
echo $out
}
# allow a previously kicked user access
function unkick ()
{
rules=`sudo ipfw list | grep -s $1 2>&-`
nip=`ip $1`
nrules=`sudo ipfw list | grep -s $nip 2>&- | sed s/$nip/$1/g`
if [ ${#rules} = 0 ] && [ ${#nrules} = 0 ]; then
echo "No matches for $1 ${nip:+or} $nip"
else
echo "${rules:-$nrules}"
echo -n 'Enter the rule number to delete:'
read rulenum
sudo ipfw delete $rulenum
fi
}
# return all connections to the computer
function connections ()
{
network=`netstat $* -Wp tcp | grep -s ESTABLISHED | grep -sv localhost |
grep -sv '127\\.0\\.0\\.1'`
network=`echo $network | sed 's/tcp4 *[0-9]* *[0-9]* \\
*[0-9;a-z]*\\.[0-9;a-z]*\\.*[0-9;a-z]*\\.//g'`
network=`echo $network | sed 's/ESTABLISHED//g'`
network=`echo $network | sed 's/ / /g'`
# output nicely
if [ ${#network} = 0 ]; then
echo 'No Active Internet Connections'
else
echo 'Active Internet Connections'
echo 'Local Port Foreign Host Address'
echo "$network"
fi
}
# Return what music files are being listened to remotely
function whatmusic ()
{
music=`sudo lsof -Fn | grep /Volumes/Music/iTunes\\ Music/ | sed 's/n\\/Vo
lumes\\/Music\\/iTunes Music\\///g'`
if [ ${#music} = 0 ]; then
echo 'No music being played'
else echo "$music"
fi
}
# search this file for an alias/function
function forget () {
grep -iA1 $1 ~/Library/init/bash/aliases.mine
}
function forgot () {
grep -iA1 $1 ~/Library/init/bash/aliases.mine
}
And my rc.mine file:
# The Command prompt
export PS1="\\[\\e[36;31m\\][\\A \\u
\\[\\e[36;0m\\]\\[\\e]2;\\h
export LS_COLORS='di=00;34'
Oh, and one quick question: In TCSH, I could set an environment variable that allowed me to do case-insensitive tab-completion. Is there a variable like that in bash?
1>&2
does...
It pops up in all sorts of places, and there's no man page for stuff like that.
Any ideas?
Originally posted by 1337_5L4Xx0R
hey bauman, I've always wondered what stuff like:
1>&2
does...
It pops up in all sorts of places, and there's no man page for stuff like that.
Any ideas?
Quite honestly, I have too. It really doesn't seem to make much sense to me.
Here's what I've been able to grok together... please excuse any inaccurate comments, and correct me on it. I'm still learning.:
Edit: WARNING: You are embarking on a long post. It should be helpful, and I don't think you should get lost, but it will take a bit. Consider yourself WARNED
It has to do with the output of commands. I'm sure you've got that far, too, but I want everyone on board.
A command outputs different things with a 'descriptor' number that says what kind of a message it is. So, 1 is typically regular output, also called stdout. However, if a message outputs an error, it gives output with the descriptor 2, also called stderr. Then there are another 125 numbers that I think just are used for different types of errors. I haven't run into any descriptor that is greater than 2.
Ok, so now the '>' character is for redirection. You take something from the left side, and put it into the right side. Simple enough, right? So, from what I can tell, the 2>&1 takes output with a descriptor of 2, and adds it into output with descriptor 1. Clear as mud I'm sure.... nothing like a good example to clear things up.
We'll do a simple variable assignment. The syntax is really easy, you just do something like this:
$ var=123
Almost every place you use this variable after the initial assignment it must be preceded with a $ sign (Don't confuse this with the $ I put in the code.... that's just to signify that it's a command line... and since we are in a "bash tcsh" topic-pun intended, I can't simply use a %
$ echo $var
You should get on the next line the contents of the variable, instead of $var. Everybody still with me? One more thing before we get into output. A way you assign a variable to the output of a certain command is with `backticks` (the key below escape and above tab). So, here's an example:
$ test=`echo "Hello, this is a test"`
$ echo $test
Hello, this is a test
To retain the whitespace formatting of a variable, put it in double quotes, like this:
$ network=`netstat -p tcp`
$ echo "$network"
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 localhost.1033 localhost.952 ESTABLISHED
tcp4 0 0 localhost.952 localhost.1033 ESTABLISHED
tcp4 0 0 localhost.ipp *.* LISTEN
tcp4 0 0 localhost.1033 localhost.1020 ESTABLISHED
tcp4 0 0 localhost.1020 localhost.1033 ESTABLISHED
tcp4 0 0 localhost.1033 *.* LISTEN
That should be enough variable preface to get through my example. Oh, and I'll use the command 'cat', which simply displays the contents of a text file.
Here's a command that outputs an error:
$ cat wrongfilename
cat: wrongfilename: No such file or directory
It gives an error as output which makes sense, because there isn't a file named wrongfilename, and it's trying to read from it.
OK. Simple enough. Let's throw a wrench into things. Lets take the command above (which gives an error), and send it's output into a variable
$ data=cat wrongfilename
cat: wrongfilename: No such file or directory
$ echo $data
$
Uh, oh. We still see the error on the terminal. When we assigned a variable to output from an echo command, nothing showed up. Look at what is in the variable data. Nothing?!? That's odd.
The answer is that variables are only assigned to the standard output (1) of a command. So, what is happening is that cat is returning an error (output of type 2), and instead of getting put into the variable "$data", it gets returned to the terminal screen. Since it's not sending anything out as type 1, nothing gets put into the variable, and it is still null (echo puts a newline on everything, even a null).
So, we need to make the cat command change it's error from type two to type 1, so it goes into the variable correctly. The way we do that is with the redirection character. I haven't perfected the syntax on this one... I've just stolen it from examples I've seen elsewhere. So, let's do this:
$ data=`cat wrongfilename 2>&1`
Aha! OK, so nothing got returned to the terminal screen, like it did last time. That's a good sign. Now try
$ echo $data
cat: wrongfilename: No such file or directory
Yay! Now we have the output from the cat command going into the variable, since we redirected the output in type 2 to type 1, and that's what the variable picks up.
Now, for a trickier example. The traceroute command shows all the internet gateways a message goes through to get to the destination. We'll do something easy like this:
$ traceroute 127.0.0.1
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
1 localhost (127.0.0.1) 0.497 ms 0.175 ms 0.076 ms
127.0.0.1 is called the loopback address. It simply is an alias for the ip address of the computer that you are on. So, congrats. You've found your own computer
Back to the point, try setting a variable to the output of this command. You get something like this:
$ data=`traceroute 127.0.0.1`
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
$ echo $data
1 localhost (127.0.0.1) 0.521 ms 0.153 ms 0.065 ms
WHAT!?! What's happening? OK, so, obviously, the creators of the traceroute command thought that it was a good idea to only have the substance of the route trace as standard output (1). Makes sense, I suppose. But then you have this strange side effect of getting what looks like an error message when you assign a variable.
So, if you play around with things a little bit, try this:
$ data=`traceroute 127.0.0.1 2>&1`
$ echo "$data"
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
1 localhost (127.0.0.1) 0.508 ms 0.158 ms 0.07 ms
Ahh, good. That's what we're looking for. So, what was happening was the header was being put out as an error message, and the terminal screen was picking it up, but the variable wasn't.
Lets try some more stuff out. What if I try to overwrite the output of type 1 with the output of type two, instead of tacking on to it? I assume the & character makes the command keep the original output of type 1, and just reassign type 2 output to type 1. Let's try doing a simple 2>1:
$ data=`traceroute 127.0.0.1 2>1`
bash: 1: Permission denied
Hmm. That's odd. OK, well I've looked around on this before, and I've seen this syntax used:
$ data=`traceroute 127.0.0.1 2>&1 1>&-`
$ echo $data
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
The structure itself makes sense, but it seems out of order to me. Ok, so the 1>&- obviously means that we are getting rid of the output with type 1. But didn't we just reassign the output from 2 to 1? Shouldn't that have gotten clobbered, too? This is where I lose myself, and I don't know where to go from here. If we try it in the order I think it should go in, it looks like this:
$ data=`traceroute 127.0.0.1 1>&- 2>&1`
bash: 2: Bad file descriptor
WHA? I've also thought that it might be a good idea to take all the types of output and redirect them into type 1. like this:
$ data=`traceroute 127.0.0.1 *>&1`
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
$ echo $data
1 localhost (127.0.0.1) 0.504 ms 0.152 ms 0.072 ms
Obviously, this isn't working like I want it to.
Hopefully someone can pick up from here for me.
It's all in the man page, if not especially clear (<- major understatement.) I won't even try to rehash all of what's written there, just a few salient points.
1) The ">&" operator is for duplicating file descriptors. So "2>&1" says to make stderr a duplicate of stdout, so stderr will go to the same place as stdout, in effect merging the two.
2) As for the order of the redirections, I've stared at this for a bit and justify it as follows:
$ cat file 2>&1 1>&-
The reason this is correct is that first, stderr is created as a duplicate of stdout. That is correct. Then, stdout is "closed". The important thing is that descriptor #2, stderr, is a copy of stdout, as opposed to a pointer to stdout, so subsequently closing stdout doesn't affect stderr.
Whereas, this code:
$ cat file 1>&- 2>&1
first closes stdout, then attempts to make stderr a copy of stdout, which it can't do because stdout is gone, so it reports the error. From the man page:
If the digits in word do not specify a file descriptor open for output, a redirection error occurs.
("word" refers to the expression after ">&") So that is why the error is reported.
Similarly, the first example in the man page actually makes sense to me now:
Note that the order of redirections is significant. For example, the command
ls > dirlist 2>&1
directs both standard output and standard error to the file dirlist, while the command
ls 2>&1 > dirlist
directs only the standard output to file dirlist, because the standard error was duplicated as standard output before the standard output was redirected to dirlist.
Again, the key here is that the >& operator makes a separate copy of the descriptor. In the first example, stdout is redirected to dirlist, and then stderr is copied from the redirected stdout. In the second example, stderr is copied from the original stdout, then stdout is redirected, not affecting the copy.
I don't know if that makes sense to anyone else, but I'm satisfied.
3) This example you tried:
$ data=`traceroute 127.0.0.1 2>1`
bash: 1: Permission denied
tries to redirect stderr to a file named "1". Perhaps you didn't have write permission in that directory, or there was already a protected file named "1". Otherwise it should work, though not the way you intended. The standard redirection operator ">" assumes the expression on its right is a filename; to do what we're doing here you want to copy descriptors, as described previously.
4) I don't know about the "*>&1" notation; I can't see in the man page that wildcards are allowed as file descriptors. That doesn't mean it doesn't exist, just that I can't find it, and haven't seen it before...
Clear as mud?