All,
I want to execute a unix statement in expect script.The unix statement outputs rsize value for a process. I haven't programmed in expect before.
This is my code:
#!/usr/bin/expect
set some_host "some host"
set Mycmd "top -l 1 -stats pid,rsize,command | grep Process_Name| awk '{print \$2};'"
spawn telnet localhost $some_host
expect "login:"
send "myDevice\r"
expect "Password:"
send "$password\r"
expect "\$"
send "$Mycmd\r"
When I execute this, I don't get any output. What's the correct syntax to execute the unix statement? How do I get this to work so that I get the correct rsize value as the output?
Always a good idea to try to escape with ascii, try \0442 for \$2 or try something like \\$2
.Also you can debug the script to find why you have no output if you insert 'exp_internal 1' without quotes at the second line.
Is it possible to get the output without having to add the "interact" statement
Yes, it is. Other statements which wait for the output will also do; you could add e. g.
expect -re "\n\[0-9]+"
to the end of your script.
Related
I'm confused when i should use awful.spawn and when to use awful.spawn.with_shell. To me these look and work the same.
The only difference I see is that in awful.spawn you can set client rules and make a callback.
I would appreciate any examples or rules on when to use each one.
awful.spawn.with_shell really does not do more than spawning the given command with a shell: https://github.com/awesomeWM/awesome/blob/c539e0e4350a42f813952fc28dd8490f42d934b3/lib/awful/spawn.lua#L370-L371
function spawn.with_shell(cmd)
if cmd and cmd ~= "" then
cmd = { util.shell, "-c", cmd }
return capi.awesome.spawn(cmd, false)
end
end
So, why would one want that? Some things are done by shells. For example, output redirections (echo hi > some_file), command sequences (echo 1; echo 2) or pipes (echo hello | grep ell) are all done by a shell. None of these work when starting a process correctly.
Why would one not want a shell? For example, argument escaping is way more complicated when a shell is involved. When you e.g. want to start print a pipe symbol (no idea why one would need that), then awful.spawn({"echo", "|"}) just works, while with a shell you need to escape the pipe symbol the appropriate number of times. I guess that awful.spawn.with_shell("echo \\\|") would work, but I am not sure and this is the point.
Also, a shell that does nothing is an extra process and is a tiny bit slower than without a shell, but this difference is really unimportant.
I'm facing a problem while trying to pass a variable value to a grep command.
In essence, I want to grep out the lines which match my pattern and the pattern is stored in a variable. I take in the input from the user, and parse through myfile and see if the pattern exists(no problem here).
If it exists I want to display the lines which have the pattern i.e grep it out.
My code:
if {$a==1} {
puts "serial number exists"
exec grep $sn myfile } else {
puts "serial number does not exist"}
My input: SN02
My result when I run grep in Shell terminal( grep "SN02" myfile):
serial number exists
SN02 xyz rtw 345
SN02 gfs rew 786
My result when I try to execute grep in Tcl script:
serial number exists
The lines which match the pattern are not displayed.
Your (horrible IMO) indentation is not actually the problem. The problem is that exec does not automatically print the output of the exec'ed command*.
You want puts [exec grep $sn myfile]
This is because the exec command is designed to allow the output to be captured in a variable (like set output [exec some command])
* in an interactive tclsh session, as a convenience, the result of commands is printed. Not so in a non-interactive script.
To follow up on the "horrible" comment, your original code has no visual cues about where the "true" block ends and where the "else" block begins. Due to Tcl's word-oriented nature, it pretty well mandates the one true brace style indentation style.
I need to get different SFTP exit codes for each error. For instance 'no such file or directory' --> exit code=552 or 550 instead of returning 1.
I've tried the following and it did not work:
//A05FTP EXEC PROC=SFTPROC,COND=(0,NE)
//COPSFTP.MYSTDIN DD *
host="xpto.xpty.xptz"
lzopts mode=text
cd /home/apl/files/unl
ls
a=`ls | wc -l`
echo `$a`
echo $?
QUIT
//*
and the output in spool is:
cozsftp> lzopts mode=text
mode=text
cozsftp> lzopts mode=text
mode=text
cozsftp> cd /home/apl/files/unl
Ý09.807¨ Invalid command.
cozsftp> a= 1
CoZBatchÝI¨: returning rc=exitcode=1
Can anyone help me?
COZBATCH allows you to embed shell scripts into JCL, so you don't need to use BPXBATCH. BPXBATCH really is a poor utility. If you're using Co:Z then good for you it rocks.
If you want to run shell commands you need to use the ! escape character.
!echo $a
FWIW, SFTP always returns 1 on error. I'm not sure if you can change that. Errors should be logged in the sysout.
Your problem may simply be the echo `$a`. Try enclosing with quotes instead of tick marks.
More generally, if you want to do more detailed error checking, instead of using the SFTP procedure (SFTPROC), I think you'd do better to write yourself a simple script that you execute with BPXBATCH. The script would issue the same SFTP commands, but you could capture and redirect the output (STDOUT/STDERR) and based on the return value ($?) and any error messages, you could certainly detect all the unusual conditions you might want.
For example,
I executed "pwd" and it shows the current working directory. Then if I want to reuse that result in my another command, it would convenient to get it via a Unix command or built-in variable. Does it exist?
You can get the result, as in return code, using $?. In order to get the output you'll need to explicitly keep it around - e.g. with:
MYVAR=`pwd`
echo $MYVAR
Use $? inorder to get the status of the last executed command. Its value will be zero if the last executed command was successful else non zero.
The internal variable $? holds the return value of the last executed command or program. Example: http://tldp.org/LDP/abs/html/complexfunct.html#MAX.
If you don't need to run one command first, you can also try using pipes | to connect commands. I am constantly piping long directory listings over to more, so I can page through the results, with
ls -al | more
so if you want to use the results of running pwd as input to another program, you can try something like piping the results of pwd over to more with
pwd|more
The following statement work at command prompt. But does not work in a cron.
myvar=`date +'%d%m'`; echo $myvar >> append.txt
The cron log shows that only a part of the date statement is run.
How do I use it in a cron?
Escape the percent signs with a backslash (\%).
My general rule of thumb is "do not write scripts in the crontab file". That means I don't place anything other than a simple script name (with absolute path) and possibly some control arguments in the crontab file. In particular, I do not place I/O redirection or variable evaluations in the crontab file; such things go in a (shell) script run by the cron job.
This avoids the trouble - and works across a wide variety of variants of cron, both ancient and modern.
from man 5 crontab:
The sixth field (the rest of the
line) specifies the command to be run.
The entire command portion of the line, up to a newline or % character, will be
executed by /bin/sh or by
the shell specified in the SHELL variable of the cronfile.
Percent-signs (%) in the command, unless escaped with backslash (), will be changed into
newline characters, and all
data after the first % will be sent to the command as standard input.
Your %s are being changed to newlines, and the latter part of your command is being fed to the command as stdin. As Ignacio says, you need to escape the %s with a \