$ if [ false ]; then echo "That was a true statement"; fi
LinuxInAlaska wrote: » The [] implement the test command. The test command sees false as a string not a command. Because it sees it as a string, the test command tests to see if it is non-zero length. Because it has length, the test command returns a true. Therefore the echo command is executed. You could make this work right by just leaving the brackets off.
paul78 wrote: » Interesting.. I will have to look closer. When I looked at it, I thought that it was because/bin/false returns a non-zero exit code which is evaluated to true.
lsud00d wrote: » The expression resulted in an exit status of 0, resulting in the echo
false
[ false ]
ChooseLife wrote: » [ false ]
paul78 wrote: » @chooselife- I would have to agree with @linuxinalaska then. To your other question about using/bin/true- that command also returns exit code of zero as I recall so the echo is not executed is command substitution was used in the expression.
$ if [ true ]; then echo "That was a true statement"; fi
lsud00d wrote: » It can be [ abc ] or [ 123 ]...because it's ([ ended by ]) aliased to test which is simply evaluating it as a string, which returns exit status 0 and executes the echo
$ if false ; then echo "That was a true statement"; fi
$ cd TrashCan; rm -rf *
ChooseLife wrote: » Question #2: Suppose there is a TrashCan directory that you want to empty. Why is the following approach bad? How would you fix it?$ cd TrashCan; rm -rf *
$ cd TrashCan && rm -rf *
rm -rf TrashCan/*
marco71 wrote: » Second command, rm -rf * , (because of ; separator), will always be executed, no matter if first command fails or not (for example, if TrashCan is a hidden folder, then cd TrashCan fails, shoud be cd .TrashCan)... and will erase all current folder if cd command fails
marco71 wrote: » correct would be to use && separator for the two commands, in this way, second command is executed only when first one returns true: $ cd TrashCan && rm -rf *
$ sudo cd TrashCan && rm -rf *
mkdir -p myProject/{src,doc/{api,system},tools,db}
ChooseLife wrote: » Question #3. So we established that one safe way to clean up a directory is to execute: $ cd TrashCan && rm -rf * Now suppose TrashCan's permissions do not allow the user access its content. Is there anything wrong with the following line? $ sudo cd TrashCan && rm -rf *
log32 wrote: » Very nice thread, this is an easy one:what is the directory structure of this command ? mkdir -p myProject/{src,doc/{api,system},tools,db}
hiddenknight821 wrote: » Oh, c'mon. Could you at least give us questions that's at the same level as ChooseLife's? His questions actually made me ponder.
hiddenknight821 wrote: » Without cheating, I'd say the first operator (the expression before the double ampersands) would be evaluated as true as long as the correct password is provided. Thus, the last operator would be executed. However, it will not run the `rm -rf *' command on the TrashCan/ directory. It'd be committed to the current directory instead.
log32 wrote: » mkdir -p myProject/{src,doc/{api,system},tools,db}
lsud00d wrote: » TBH I had to think about it. It's not very often I'm mkdir'in beyond the dir needed and it brings an element of "order of operations" a la mathematics to properly evaluate the parent switch directory creation. Same thing with recursive commands...if you don't go beyond what you're doing in that specific directory the specifics can escape you.
ChooseLife wrote: » Good answer. It is partially correct, but does not cover the main "tricky" part of this question