Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
Excuse me, I don't mean to hijack your thread, but I wonder if Chris can elaborate on the use of "==" for testing here?
It appears by Saratha's snippet that (in essence) IF "$num" is equal to exactly "0" ; then do_work; else go_home; fi
What's the benefit of say
if [[ -n $num ]] ; then do_work; else go_home; fi
? Would that work?
so, from some cursory peeking at man bash it appears that
True if the length of string is non-zero.
string of "0" vs empty ("")space?
num=$(ls -l|wc -l) here in an empty directory produces
[[ $num == 0 ]]
will never happen?
I guess the question to ask is are we testing for empty "$num" using "num=$(ls -l|wc -l)"?
(ls -l|wc -l) gives us 1
(ls *|wc -l) gives us 0
Am I confused? Definitely.
I don't understand when one should use
[[ $variable == 0 ]] or [[ -n $variable ]]
and I'll probably go "oh snap!" 5 seconds after posting this
If I understand you (Habitual) correctly, the point of not using -n is because even in an empty dir, wc returns '0' which has length(!) eg
# tmpx is an empty dir ...
if [[ -n $v1 ]]
echo "v1 $v1 has len"
# output is
v1 0 has len
Chris: I just want to know an example of when to use "== 0" or when to use '"-n "$VARIABLE"' and how to test for an empty directory.
You didn't quote your variable, how come?
if [[ -n "$v1" ]]
The output with or without quotes is identical, I just thought it is 'good form' to always quote your(?) variables and use them in upper case.
I also only know that the OP's code snippet begged me to ask "What are you trying to do there?"
I am an odd duck and I don't really have anything to contribute to this discussion except inquiries into my own ignorance.
and I love to code.
Re quotes round tested vars; really it depends on how well you know your 'data'. Obviously the most general rule is to use quotes (in case of spaces & other 'odd' chars), but I don't bother unless I know or think I'm going to need to.
It just makes the code 'noisy'.
I'm old school *nix (about 15 yrs usage or so) and never use spaces in filenames etc. OTOH, if you're not the data producer, you may not get a choice eg MS files via Samba.
I'm sure david_the_h would insist on quotes all the time
This leads into the concept of writing shorter/faster code for data processing if you can reasonably rely on the type of values and their range. It may enable you to use shortcuts, rather than always having to use a general soln which will take more (&/or more complex) code, be harder to maintain & take longer to run for instance.
Its really a judgement call
PS Of course you also need good error handling ...
well it's worth nothing that you'd only need quotes if you're using [ / test. Using [[ wouldn't need them as it tokenizes the variables within bash. Does of course make it bash specific though, so it's not as portable.
Yes, I would recommend quotes pretty much all the time. Not just because of word-splitting, but because any globbing characters are interpreted too. You could conceivably end up with a list of filenames instead of the string you expected.
The only time I'd feel safe leaving them off is if you know what you're doing and are certain that there's no chance of surprises. Variables that only contain digits, like counters, are generally safe. But even then it never hurts to keep in the habit and use them anyway.
As for the OP topic, parsing ls like this is not generally recommended. Although to be fair the only real danger comes from the rare chance of a name containing a newline. So I wouldn't argue against it for a quick&dirty count, for a real script you should probably use something more robust.
Assuming a single directory with no recursion, a simple loop is all that's required.
shopt -s dotglob
for fname in *; do
[[ -f $fname ]] && (( count++ ))
In more advanced cases you may want to load the matching files into an array. That would let you grab the first/last file, for example.