When it comes to manage my pictures library, I must admit I am very undisciplined. I usually let pass many months between the time I take a picture and the time I transfer it to my computer so it is very hard to organize them by the date they were taken. Moreover, I am sometimes in a hurry so I just transfer them in a “temporary” place telling myself that I will organize them later (sure…).
In short, for years, my pictures library has been a total mess. Lately, I wanted to see my child evolution through years and months to finally quickly realize that my neglicence has made this simple task now impossible. In the end, all I wanted was to organize them by the date they were taken, not by the event they were attached to.
I recently solved my problem by writing a short bash script that does exactly that. First the script scans a source folder looking for jpg or jpeg files. Now for each file found, the script will look at his EXIF information (if it is not possible, the creation date of the file will then be used) to determine the date it was taken and copy it in a destination folder in an organized way using a Year, Month and Date format. Files with the same name will be automatically renamed and you can choose to copy (default) or instead move the pictures found.
The basic usage is the following one:
[hudony@fedh ~]$ ./organizePictures.sh -h
Usage: ./organizePictures.sh [-moqh] SOURCE DESTINATION
-m Use move instead of copy
-o Overwrite duplicate files instead of renaming them
-q Quiet, do not display informations on the console
-h This help message
Continue reading “Organize your pictures according to the date they were taken” »
Share your thoughts
If just like me, you are using logrotate to manage your logs, you are probably also using its “compress” options (if not, then you should) which gzip (by default) the log after rotating it in order to save up some space. Recently, a customer called me complaining that he didn’t receive an email sent to him few days ago. I then proceeded to ask him which exact day the email was sent but he wasn’t sure since the sender had emptied its “sent items” list (???).
In short, I had to find it through all my postfix log files (we keep a week long and daily log files are compressed). The usual way would be to unzip and analyze each log file until we find what we are looking for. Doing that for 7 files isn’t that bad but what If we had 30 files to analyse, there must be a better way…
Indeed, to quickly solve this issue, you can use a for loop and the cat command :
[hudony@smtp log]# for i in $(ls maillog*.gz);do gunzip -c $i >> /tmp/logfile; done
The result is only one log file (which could be very big so be careful) containing all the useful data.
Share your thoughts
I recently built a Postfix/Courier-IMAP server with virtual domains that uses maildirquota to enforce quotas limitation. Migrating from a H-Sphere setup, I couldn’t ignore the fact that despite all its flaws, it had a very useful built-in feature: it could send an email to a user when this one was about to exceed its quota.
Since the machine was now offline, meaning I couldn’t find anymore the script executing this task, I decided, after quickly looking on the internet for one, to write my own. Here it is in Bash :
Note that this script uses mutt since I am usually sending HTML emails. Should you be fine with text emails, you can use the mail command.
#!/bin/bash
ratio=90
for dir in /var/mail/vhosts/*
do
for mailbox in $dir/*
do
rawQuotaSize=$(head -n1 $mailbox/maildirsize 2>/dev/null)
if [ ! -z ${#rawQuotaSize} ]; then
quotaSize=${rawQuotaSize%?}
alertQuotaSize=$(($quotaSize * $ratio / 100))
mailBoxSize=$(du -sb $mailbox | cut -d"/" -f1)
if [ $mailBoxSize -gt $alertQuotaSize ]; then
email=$(echo "$mailbox" | cut -d/ -f6)@$(echo "$mailbox" | cut -d/ -f5)
echo "Optional email body" | mutt -s "You are now at $ratio% of your
allowed storage capacity" -e "set content_type=text/html"
-e "set realname = \"donotreply\"" $email
fi
fi
done
done
The script is self-explanatory: it loops through each mailbox of each virtual domain and for each, get the mailbox’s quota. If a quota is set, it then check if the current size of mailbox is greater than the ratio * the mailbox quota. If so, an email is sent.
Download quotaAlert.sh
Share your thoughts
Let’s face it. Sometimes, we have to make a quick edit of a file directly on the production server. These changes are usually very small things : typo, formatting issue, visuals etc. that we don’t want to test on our development environment being sure that they will work out of the box since they don’t involve code logic modifications. You then save the file only to realize few minutes or hours (ouch) later that you triggered a fatal error for, let’s say (the classic), a forgotten semicolon between two instructions.
Here is a quick tip that will avoid such situations. After saving those “risk-free” code modifications, execute from the commande line on the server the following :
[hudony@fedh script]$ php -l checkSimulation.php
No syntax errors detected in checkSimulation.php
The -l flag will check the PHP syntax for you and report any error that could cause the file from being not executed properly. This way, you can quickly spot a fatal error in a matter of seconds instead of minutes or hours when doing “risk-free” modifications ;)
Share your thoughts
It happens, you are working very hard on a project, being fully concentrated (and you are using GIT of course) and in the middle of your work, your boss or a co-worker ask you to stop whatever you are doing to correct an important bug someone just found. Worst, the correction you must do relies on the previous version of the file you have been editing for hours… Fortunately, GIT let you handle a situation like this with a relative ease.
The “usual” way to address this situation is to commit your changes on a temporary branch you’ve just created then check-out a “clean” branch to work with, correct the bug then resume your previous work by checking-out your temporary branch again. What many are not aware of is that GIT can also let you handle the same situation much more easily with git-stash.
Git-stash let you quickly and easily put aside what you were doing to resume it later when convenient for you. By using git-stash, one can achieve the above result with only two commands. Let’s use a real-life example and say you have the following working tree to begin with :
As we can see, we are working on changes that have not been commited yet. Then comes the urgent request so we must leave what we were doing and start working on it and for this, we use git-stash :
[hudony@fedh ediffuzion]$ git stash
Saved working directory and index state WIP on master: 71ba884 Bug replace
HEAD is now at 71ba884 Bug replace
See, GIT created by itself our “temporary” branch (stash). We can now start working on the new request and when done, commit our changes to end up with a tree looking like this :
Once done, we are ready to resume our previous work by using git-stash pop :
[hudony@fedh ediffuzion]$ git stash pop
# On branch master
# Changes not staged for commit:
# (use “git add <file>…” to update what will be committed)
# (use “git checkout — <file>…” to discard changes in working directory)
#
# modified: www/accounting.php
#
# Untracked files:
# (use “git add <file>…” to include in what will be committed)
#
# www/images/loading2.gif
no changes added to commit (use “git add” and/or “git commit -a”)
Dropped refs/stash@{0} (827ff43984ceab98a101aa94949938780713fee7)
Here is our working tree afterwards:
There you go, right were you left and ready to continue… until the next disturbance!
Share your thoughts