I remember quite some time ago when I was developing a an application when the personal computer was actually fairly slow. \u00a0Of course I happened to pick a technology that worked just fine on a newer computer but it actually ran quite pokey on my machine.<\/p>\n
The decision was made to never develop on a machine less than or equal to the target platform. \u00a0Fast forward a few years to discover that I periodically get stuck with the slow development environment and there is nothing that I can do about it.<\/p>\n
Well, I can’t speed up the machine but I can make my programs and scripts a bit smarter. \u00a0The target of my focus was a small script that called some horribly inefficient java program. \u00a0Not all the programs dawdled, just this one.<\/p>\n
The problem was the script called this program even though in most cases the input directory was empty – not a problem on production but really slow on development.<\/p>\n
The input directory can hold quite a few data files and the names are never the same. \u00a0I ran through a few different ideas.<\/p>\n
Well, it seems to be a pretty strait forward solution. \u00a0Get a count of the number of files and then you will know how many things there are to process and thus if there is anything to process.<\/p>\n
It almost makes sense until you try this. \u00a0It works just great when data does exist but when no data exists then it doesn’t work very well.<\/p>\n
#!\/bin\/bash\r\n\r\nEXT=xml\r\nINPUT=\/data\/input\r\n\r\nCNT=`ls -1 $INPUT\/*$EXT | wc -l`\r\nif [ $CNT -gt 0 ]\r\nthen\r\n echo $CNT items\r\nelse\r\n echo \"files don't exist\"\r\nfi\r\n<\/code><\/pre>\n<\/div>\nThe count variable is set to zero but the the shell informs us that no data exists.<\/p>\n
ls: cannot access \/data\/input\/*xml: No such file or directory<\/em><\/strong><\/p>\nNot a serious issue but depending on the person very distracting.<\/p>\n
<\/p>\n
Idea #2<\/h2>\n
This error message can be easily gotten rid of. \u00a0Simply redirect the error output to a file or to \/dev\/null.<\/p>\n
\n#!\/bin\/bash\r\n\r\nEXT=xml\r\nINPUT=\/data\/input\r\n\r\nCNT=`ls -1 $INPUT\/*$EXT 2>\/dev\/null| wc -l`\r\nif [ $CNT -gt 0 ]\r\nthen\r\n echo $CNT items\r\nelse\r\n echo \"files don't exist\"\r\nfi\r\n<\/code><\/pre>\n<\/div>\nNot a bad idea if you know that the directory permissions for the input directory will always be OK. \u00a0If not, then you will be (possibly) throwing away the only help to diagnosing an odd behavior.<\/p>\n
testing\u00a0existence\u00a0– Extra credit edition<\/h2>\n
This second solution is quite acceptable and unless it is called a lot it shouldn’t be too much overhead. \u00a0Yet there is a much easier solution that is probably even more efficient.<\/p>\n
\n#!\/bin\/bash\r\n\r\nEXT=xml\r\nINPUT=\/data\/input\r\n\r\nls $INPUT\/*$EXT >\/dev\/null 2>&1 \r\nif [ $? -eq 0 ]\r\nthen\r\n echo $EXT files exist\r\nelse\r\n echo \"$EXT files don't exist \"\r\nfi\r\n<\/code><\/pre>\n<\/div>\nNo, you don’t know the number of files, but you don’t have to create a pipe and fill it with a few (or many) files just to decide whether or not to run a program. \u00a0Simply look at the Unix return code from our last command, if zero, then we know our files exist.<\/p>\n","protected":false},"excerpt":{"rendered":"
I remember quite some time ago when I was developing a an application when the personal computer was actually fairly slow. \u00a0Of course I happened to pick a technology that worked just fine on a newer computer but it actually … Continue reading