Legendary for it's power, crypticly simple these are the things I've come to use and enjoy most abou the unix command line and standard binaries.
grep -Rni "phrase" *
grep searches for text, these flags recursive (-R) to search all directories and subdirectories, -n to show the line number, and then -i for a case insensitive search.
combined with other tools can do very cool things.
grep -Rni "phrase" * | cut -d ':' -f 1 | sort -u
The pipe to cut is parsing each line by splitting on the ':' character and then showing column 1, sort -u sorts the lines and then shows each value only once, so files listed will not be repeated, which happens in this case if the phrase occured in them more than once.
wksp files
Workspace files, abrieviated wksp, is a convention I've grown to love. in most of the projects I work on I place a file in the root directory named wksp which looks about like follows
#!/bin/sh
e(){ vim myproj.c; }
mkdir -p ./build;
c(){ cc -o ./build/myproj myproj.c -lfirecrow; }
d(){ cat file-to-filter | ./build/myproj; }
and I run it as follows
. ./wksp
the wonderful part about it is that by importing those one letter functions into my local bash shell I can quickly kick off the things that I do most repetitively, in this case open a file. compile the file, and then run the binary.
and usually when I am in the middle of doing something, I just hack away at the functions by redefining them on the fly.
like...
e(){ vim otherfile.c; }
if i'm going to be editing another file for a while or...
e(){ grep -Rni ../files/stuff | vim otherfile.c; }
if I want to change how I run the file.
return code in ps1
Another fantastic thing to do for enhanced visibility into whats happening on the command line is to set the return code as part of the PS1, the part of the command line prompt that is printed when it's ready for another command.
this is what mine looks like
0
Its just a zero, which is the return code for as long as the commands I write are successfull. and whenever something is not successfull, in addition to the stderr messages that get printed to the screen I see the return code.
0 ls nothere ls: cannot access nothere: No such file or directory 2
which is awesome because then I know what the exit code was of the process.
here is what I put in my .bashrc or .kshrc files
cecho (){
local _clr=$1;
shift;
echo -e "\033[${_clr}m"$@"\033[0m";
}
export PS1='$(_r=$?; if [ $_r -eq 0 ];then _clr="35"; else _clr="33"; fi; cecho ${_clr} " $_r " )';
colored output
Ansi escape codes for color output are particularly cool. the terminal colors are 30-37 for black through colors and white for foreground, and 40-47 for background. the postfix m stands for color and using the ansi escape code "\033[" you can create colored output like this...
0 echo -e "its not easy being \033[42;30m green \033[0m" its not easy bein green
This is especially helpful for differentiating what comes out of stderr vs stdout.
0 yellow(){ > while read line; do > echo -e "\033[33m$line\033[0m"; #33 for yellow > done; > } 0 grep -Rni "because" * 2> >(yellow) 1:118:To me this is wonderful. Not because I enjoy.. 51:95:because variables can be references to functions, and the appropriate 51:104:this is because a scop chain context is build for each executing 63:168:contains files for a player that runs outside the browser. I like the... grep: articles: Permission denied
stdout and stderr seperated is awesome
Once it hit me it was so impressive, stderr used to be just that odd other channel that was a unix formality, until I had a socker server I was directing the output of to a datafile to use later and wanted to send debuging information to the screen at the same time, and low and behold there's this great convention for doing that.
Send everything that will be used by something else to stdout, and any other status messages of any kind to stderr. The name stderr is misleading in some ways it's it could be renamed std_message or std_status but that would break convention unecessarily, but now I send all my debug or status output to stderr instead of just printing messages to stdout all the time.
find by containing directory
find is awesome it climbs the working directory for a file, which is great on the fly, but can be slow. because there are more files than directoris, using find can be accelerated by searching only directories and then searching for files only within the expected directory.
0 for dir in $(find ./ -name mydir -type d); do find $dir -name myfile; done
To find file myfile in a containing dir mydir.