As a part of my tcl script, my requirement is i need to delete contents (i.e. files and directories with my login id) from remote machine. So i am using following code
On May 27, 5:25 am, sunny <techbie.wordpr...@gmail.com> wrote:
> As a part of my tcl script, my requirement is i need to delete > contents (i.e. files and directories with my login id) from remote > machine. So i am using following code
I find it hard to believe that that's exactly what you use given that you say it works for some things; I suspect it got mangled during posting. (That sort of thing happens.) We need to see exactly what is being used (well, not including any passwords) in order to diagnose problems.
It would also help if you described exactly what results (independent of the side-effect of deleting stuff) you expect to get out of it.
Now this code is working only on running this on that particular machine. If i want to run this code from a remote machine, this is still not working.
I have lot of machines (linux, solaris and ibm machines) where i need to perform this operation as i can't do this operation manually. I want to do this operation form tcl script only.
Now for deleting data from remote machine, i am using following code:
I'm putting the string to execute remotely in double-quotes because I want the user id to be substituted _locally_ and I'm assuming it has no evil characters in it (that's a pretty safe assumption for user names!)
Note: it doesn't need ls, or grep, or awk. (It could have been written with xargs, but there's good reasons to not do that when deleting directory hierarchies.)
> I'm putting the string to execute remotely in double-quotes because I > want the user id to be substituted _locally_ and I'm assuming it has > no evil characters in it (that's a pretty safe assumption for user > names!)
Beware that the -delete flag is a rather recent addition in 'find''s life (eg absent on RHEL4). An older syntax that works across the board:
The backslashes are doubled for Tcl substitution (passing them as singles), and then the resulting \{\} and \; are two shell-escaped arguments to 'find'.
I have read some where on net that for awk to work with tcl, you should use '{' instead of '. Now if i execute same code by logging into machine manually from tcl shell, it works absolutely fine.
Because (1) you're trying to use 'Tcl braces' in a place where Tcl's teeth cannot chew :P, and (2) you failed to protect a dollar.
Indeed, in the above, "(cd /local/test; ls -ltr | grep $userid | awk {{print $NF}} | xargs rm -rx}" is a single string passed as the 3rd argument to [exec]. Following Tcl's rules with double quotes, normal dollar+backslash +bracket expansion occurs. You do want it to dollar-expand $userid, but you don't for $NF (because you want awk to see the dollar). That's error (1), fix it by saying \$NF.
Then, none of the braces receives any special attention from Tcl's toplevel-double-quotes processing, so they go through untouched, down to the shell (spawned by rsh remotely), to which a curly brace has a completely unwanted meaning. That's error (2), fixed by using single quotes.
> I have read some where on net that for awk to work with tcl, you > should use '{' instead of '.
That's the kind of sentence that, taken out of context, does more harm than good. The truth of the matter is simply to think carefully about which programs reads which character at each level. When Tcl is behind the wheel, give it {} to protect no-expansion strings. When it's the shell, give it '. Awk has its own rules just like any other program, and is no exception to the two ones just listed:
exec awk {{print $1}} exec sh -c {awk '{print $1}'} exec sh -c "awk '{print \$1}'" exec sh -c {awk "{print \$1}"}
all end up printing column 1. Look at them in detail to understand why. After that you'll never hesitate again :)
Note that there still is a paren mismatch (the remote command starts with "(" and ends with "}") -- most probably a left-over from previous try-and-error by the OP...
> Note that there still is a paren mismatch (the remote command starts > with "(" and ends with "}") -- most probably a left-over from previous > try-and-error by the OP...
> On 27 mai, 15:53, Ralf Fassel <ralf...@gmx.de> wrote: > > * Alexandre Ferrieux <alexandre.ferri...@gmail.com> > > | So the final fixed code should be:
> > Note that there still is a paren mismatch (the remote command starts > > with "(" and ends with "}") -- most probably a left-over from previous > > try-and-error by the OP...