Archive
Posts in Shell
Converting time since the epoch to a human readable string
I was parsing some Netbackup logs today, and needed a way to convert the time since the epoch into a human readable string. A while back I read about the various forms of input that can be passed to the GNU date's "-d" option, one of these being the time since the epoch: This solved my issue, though unfortunately it's not super portable. Food for thought.
$ read more →Advanced Bash Scripting Guide
I came across the Advanced Bash Scripting guide while checking through my RSS feeds this morning. It has a ton of great examples and goes pretty in-depth on Bash scripting features. A good read for sure. =)
$ read more →Serve out content over HTTP from your cwd immediatly
Ever want to immediatly serve content from a specific directory over HTTP, but didn't want to bother messing with httpd.conf or other webserver configiurations? If you've got Python installed, this is a snap. Execute python with the SimpleHTTPServer module, using port 8080 so there isn't a need to elevate privs to root. Sure enough, pointing a browser to the IP address :8080 of the box hits my home directory listing…
$ read more →Awesome use of read-only variables in bash scripts
I was reading through Jim Perrin's CentOS hardening article, and saw one super interesting use of read-only bourne shell variables. If you have users that are frequently logging in and staying idle for days and or weeks, you can add a readonly TMOUT variable to /etc/profile: The TMOUT variable controls the amount of time a user can be idle before the system logs them out. Since the variables in /etc/profile will be applied to the environment before a users .bash* and .profile files, you can be sure that users can't override (this doesn't address users who use C shells, but that can be addresses similarly) the read-only TMOUT variable and stay idle for longer periods of time. This also works well for HISTFILE environment variable, which is mentioned in the article…
$ read more →Implementing locks in shell scripts
I have been working on a shell script that manages lxc-containers, and came across a use case last where it is possible for two yum processes to interfere with each other. To ensure that only one yum process is run at a single point in time, I implemented file based locks using flock(1). Flock makes this super easy, since it has a "-x" option to create an exclusive lock (this is the default), and a "-n" option which causes flock to exit with a return code of 1 if it can't obtain the lock. This allow code similar to the following to be used to protect sensitive areas: In my case this tiny bit of code ensures that only one yum process is able to run, which helps keep my package database in a sane state.
$ read more →