ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
the find command will only return non zero value on error, so it will return 0 if it find or not file.
A solution could be to pipe the output to grep -q who will return non zero if not found.
Something like that :
case is more efficient than [ or test when you can get by with simple pattern matches.
Hey, gnashley, thanks for the heads up: I didn't know that. In fact, I was sceptical enough to test:
time bash -c 'for F in `seq 1 10000` ; do true ; done'
time bash -c 'for F in `seq 1 10000` ; do true ; case "$F" in 50) echo 1 ; esac ; done'
time bash -c 'for F in `seq 1 10000` ; do true ; [ "$F" == "50" ] && echo 1 ; done'
time bash -c 'for F in `seq 1 10000` ; do true ; if [ "$F" == "50" ]; then echo 1 ; fi ; done'
on an Atom N270 laptop and Bash 4.1.5, the real times were 0.285s, 0.490s, 0.733s and 0.745s, respectively; meaning that ten thousand cases took +0.20s, [s +0.45s, and ifs +0.46s real time. In other words, cases took less than half the time compared to [s or ifs. Funny! But I wonder how on earth did you come across that info?
Sure, `type test` or `type [` will tell you that the internals are being used. I discovered that case was faster when I tried to optimize some really slow code where I was using brackets in multi-choice if-elif-then pattern comparisons. In my routine 'case' ran in about 30% of the time as using brackets. In the OP's example, the difference would probably less.
my issue is that on solaris -quite doesn't work. any workaround for this?
Oh, right, -quit isn't supported by all finds. Fortunately, I have a pretty devious workaround you can use instead:
FILE=`find . -name 'filename' -print -exec sh -c 'kill -TERM $PPID' ';'`
case "$FILE" in
*) echo "Found '$FILE'." ;;
Whenever the find command finds a file, it will print the file name, then exec an sh subshell that will send a TERM signal to its parent, terminating the find command. Although that will also result in exit status 143 ("killed by TERM" in Linux and Solaris at least), the most reliable way is still to check if FILE is non-empty.