All my work worth using twice is stored as distros inside our version control repository.
We use cvs. It works really well.
Some of the stuff is stored as reference in case something blows up and we need to know what was there. Such as with crontab files, sometimes they have important details- and if we had to recreate from scratch, we could forget one of those important details.
Config files are good too, httpd conf files.. The occasional log file, although rare.
Some projects can get big. So you separate them into smaller projects/module distros with test suite, documentation- and make the hell sure they work really well by themselves, stand alone.
And then some suff- some of it.. Is really better off with a ton of code. It’s rare that you really have an advantage with this- but it can happen.
In that case, maintenance is real work. But I have learned a few things over the years that have sped up and improved my ability to keep up mountains of code and hundreds of distros.
I will list some of these things here. This article will be in constant update and revision.
Look through a ton of code in your distro and open to the exact place where you find "it" via the command line.
I need to find where Cwd::Ext is in my code to change it.
1) [root@wingnut DMS2]# find ./ | xargs grep -s 'Cwd::Ext'
./lib/DMS/User.pm:use Cwd::Ext;
./lib/DMS/User.pm: require Cwd::Ext; # read in everything
./lib/DMS/User.pm: my $d = Cwd::Ext::abs_path_nd($abs) or warn("cant get abs path to [$abs]") and return [];
2) [root@wingnut DMS2]# vim ./lib/DMS/User.pm +/Cwd::Ext
Command 1) searched the current directory for all files, all directories.. everything.. and looks inside for the text 'Cwd::Ext'. The -s is error suppression for grep. For example when you run grep on files with spaces this way- you'll get errors. I don't care about that - I just want to look inside files that I know have no funny chars in the filename.
This command is actually two commands. The output of find (find ./) is piped (|) to xargs and grep.
If you didn't use xargs, the output you would be filtering 'Cwd::Ext' from would be the file listing from find. When you pass a file argument instead of a text stream to grep, it looks inside the file.
Using xargs will pass every list element as an argument to the next command.
On unix, non escaped whitespace is a delimiter, spaces, return character, etc.
Command 2) Is much more interesting.
It means to open the file in vim- and the + flag means to run the following command.
Just as you would in command: mode inside vim environment.
What we are saying in this command, is to open the file and search for string.
When the file opens, this will result in the current position to be the first line where the text 'Cwd::Ext' appears.
Very fucking cool. Very fucking convenient.
Setting colors of directory listings in bash terminal
This one I underestimated the importance of. But no more.
If you really use vim/perl/unix as I do- you are in bed with the command line. You're looking through a lot of file listings, regularly.
Using most guis, such as kde/gnome on ubuntu/fedora/suse/debian.. You'll notice when you do an ls on a directory- you most likely, by default, get some funny ephemera manifestations. What I mean is, directories may be listed in a different color. Maybe they are bold. And regular files are normal text. And some of them are in different colors!
What's up with that? Do we really give a shit if every jpg is red and every gif is blue, pdfs are purple and then notice also- JPG is not detected as a file ext to highlight and jpg *is*. Try it, change the ext of a JPG file to jpg, the color changes.
What is up with that? Well- I had been pleasantly ignoring that since- forever. I never cared to meddle or alter the settings, or even to look if there was a setting to affect that.
But recently I've been really curious to learn not just more code- more programming- but more of *how to work* more efficiently. I looked up how to affect these color and text formatted listings of directories- hoping that it may be helpful when looking through distros, through filesystems.. And you know what.. it is. Do you remember using vim and then one day actually taking the time to search and replace, properly, with capture.. And.. Wasn't it really fucking useful?
Ok, this one I know you're gonna roll your eyes at. And I did too, for years. But I would like you to take ten minutes of your life to give this a ride and see for yourself that it does help out a little. And the life of the code... These little things add up- using find xargs grep, using cv, perl one liners- and I'm gonna have to vouch for this one too. Directory listing text formatting.
- Ok, the thing you are looking to alter is a shell environment variable- on bash it's LS_COLOR.
- What is it set at currently? Run set and grep out for LS_COLOR:
$ set | grep LS_COLOR
LS_COLORS='no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;35:*.cmd=00;32:*.exe=00;32:*.sh=00;32:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.t=93:*.pm=00;36:*.pod=00;96:*.conf=00;33:*.off=00;9:*.jpg=00;94:*.png=00;94:*.xcf=00;94:*.JPG=00;94:*.gif=00;94:*.pdf=00;91'
- Alright, wtf just happened. This string tells ls that when ls --color is called, these are the colors/text formatting to use.
Now, ls --color? When have you run that flag?
This is set as an alias in some bashrc file somewhere. Likely not your ~/.bashrc. But in some /etc/$BASHRC?? file. If you want to find out in which exact place you're defaulting to use ls --color ...
$ find /etc/ 2>/dev/null | xargs grep -s 'alias ls'
/etc/profile.d/colorls.sh: alias ls='ls --color=tty' 2>/dev/null
/etc/profile.d/colorls.csh:alias ls 'ls --color=tty'
Now, how the heck is this being called??? Look at your ~/.bashrc, it may have an entry to include /etc/bashrc if it exists, and then.. well.. there's some other default profile voodoo and such I'm not versed in.
How it works..
The string value of the LS_COLOR environment variable is parsed as a hash, internally.
The stream of garble is understood as.. The delimiter is the color (:) symbol. The first part is what the element of the directory listing is, then assignment (=), and a style code. More than one style code can be assigned.
For the following chunk of string: di=00;1:fi=00:*.php=00;34, it means:
di(directory) =(assignment) 00(normal text) ;(and) 1(bold)
:(delimiter, next entry..)
fi(file) =(assignment) 00(normal text)
:(delimiter, next entry..)
*.php(everything matching *.php) =(assignment) 00(normal text) ;(and) 34(blue)
How to change it!
All you need to do to see it change before your eyes, is to go to a command line prompt, and type in:
$ LS_COLOR='di=00:fi=00;1:*.php=00;34'
$ ls
You'll notice that makes all regular files appear bold, all directories in 'normal text weight' and default color (black on white, white on black)- and php files are blue (or whatever color is mapped to that slot).
Now, if you wanted to make that change permanent (instead of only to that one terminal session you just opened)- you would enter that into your ~/.bashrc file .. as:
export LS_COLOR='di=00:fi=00;1:*.php=00;34'
Knowing the codes:
Please do note.. that's a pretty lousy string to use. It's just an example. You need to play around with it and figure out what you really want.
For that, you need to know what the codes are.. for the filesystem elements (no,li,di.fi.. etc), for setting up regexes (*.pm)- and what the codes mean (1 bold, 00 normal, 9 strikethrough).
I picked up a good list from Bartman.
Here's that same list with some extras added- these work properly on GNU bash 3.0.
0 = default colour
1 = bold
4 = underlined
5 = flashing text
6 = no change
7 = reverse field
8 = black
9 = strikethrough (cool!)
10 - 29= no change
30 = light green
31 = red
32 = green
33 = orange
34 = blue
35 = purple
36 = cyan
37 = grey
38 = underline
39 = no change
40 = black background
41 = red background
42 = green background
43 = orange background
44 = blue background
45 = purple background
46 = cyan background
47 = grey background
90 = dark grey
91 = light red
92 = light green
93 = yellow
94 = light blue
95 = light purple
96 = turquoise
100 = dark grey background
101 = light red background
102 = light green background
103 = yellow background
104 = light blue background
105 = light purple background
106 = turquoise background
My personal LS_COLOR environment variable for perl development- I have refined mine to be:
LS_COLORS='no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;35:*.cmd=00;32:*.exe=00;32:*.sh=00;32:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.t=93:*.pm=00;36:*.pod=00;96:*.conf=00;33:*.off=00;9:*.jpg=00;94:*.png=00;94:*.xcf=00;94:*.JPG=00;94:*.gif=00;94:*.pdf=00;91'
This helps me detect some things that are important to me, such as tests.t to stand out from other junk in t/, a different color for pod and pm files.. etc. very cool.
I've been using this across my servers. And it does help. It's a very small thing to do, to improve your development environment. I suggest you try it out.
