[Discuss] Strange rm behavior - solved

[gaf at blu.org (Jerry Feldman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually, using a local variable, such as RM=/bin/rm is a preferred way
to do things. You are guaranteed that you are calling the Linux command
rather than through an alias or subverted command (such as $HOME/bin/rm).

I think the issue my colleague reported was that a previous subtask was
still running. (We start a security service, and it spawns itself as a
daemon).  I think his initial problem was that he had previously started
the service (that spawns a webserver, and a few other tasks), and that
my script did not stop all of them. And in trying to debug, my command
became:
$RM rf $PROJECT
Somehow the hyphen was removed. It had to be removed today because to
try to debug I had $RM -vrf $PROJECT, so I stepped on my own toe on this.

On 09/21/2011 01:27 PM, Jerry Natowitz wrote:
> I'd be looking at the login shell initialization that is not executed
in the script.
>
> A quick and dirty is to stick "set", "alias", and "env" commands in the
script and compare the outputs to those from your login shell.
>
> My guess is some sort of globbing or nonomatch issue.
>
> ---- Original message ----
>> Date: Wed, 21 Sep 2011 13:03:45 -0400
>> From: discuss-bounces+j.natowitz=rcn.com at blu.org (on behalf of Jerry
Feldman <gaf at blu.org>)
>> Subject: [Discuss] Strange rm behavior
>> To: Boston Linux and Unix <discuss at blu.org>
>>
>>
> I have a directory that is mounted from a NAS server
> /mnts/workspaces/foobar/project
>
> In my script, the code is:
> RM=/bin/rm
> cd /mnts/workspaces/foobar
> count=3
> while [ -d project ] && [count -gt 0];do
> sleep 5 # there may be a process using a file. Wait for it to
> cleanup and exit
> $RM -rf project
> let count=$count-1
> done
>
> rm returns 0. buf fails to remove a couple of subdirectories.
> However all other subdirectories are successfully removed.
> if I execute the command '/bin/rm -rf project ' by hand it works fine.
>
> Also, I'm sure that no other process that affects this process is
> running in my test case.
>
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss at blu.org
>> http://lists.blu.org/mailman/listinfo/discuss
>

- -- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBTnotBnzqMPw7weuQAQLVlQgAsjk9C1pANxJ+KDvde/ReqXJyxUlhVGyf
7VsPLQB4Youk7ePZ2LowD+KzAHTJSJAl9NwpSmYjqmWxlWLlX4WyG5Dsrndu0Nmg
2F+3YlM7hzctRVXFGR4KKVDScwYtgZpskXa5s0pZm42NQyhOJb45UnyitE20QOpE
blc5sF73HA3nJJFrOabuLBBiOggMRRZJ560yZkhQ7x9vj5+qHjcE+P1IaP3B4blJ
KjTDNsNmnBhZFNGRO921tTeF0bZEzin/Q+Q/N1ND5BIErwL8+oLj2on6ZFyR/OX9
j/HNB+iyxsb8j5f7k1CqK2v9ZIIz99HqMnb0GGiHepcgY18drVy43Q==
=w6n0
-----END PGP SIGNATURE-----